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APPELLANTS’ APPEAL BRIEF 

This is Appellant’s Brief on Appeal pursuant to 35 U.S.C. § 134(a). The following 
sections of this Brief are the items set forth in 37 C.F.R. § 41.37(c). 

Real Party in Interest (37 C.F.R. S 41.37CC) (D (i)~) 

The Go Daddy Group, Inc., a corporation under the laws of Arizona and assignee of the 
inventors Robert R. Parsons, Joshua T. Coffman and Barbara J. Rechterman, is the real party in 
interest. 

Related Appeals and Interferences (37 C.F.R. 41.37tcJ (11 (iPl 
There are no related appeals or interferences. 

Status of Claims (37 C.F.R. S 41.37rd m fiiBl 
Claims 1 - 26 - rejected. 

Claims 1 - 26 are all of the claims present in this application. Each of claims 1 - 26 is 
imder final rejection. The claims on appeal are appended at Appendix A. 
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Status of Amendments (37 C.F.R. S 41.37(c) n't (iv)') 

There has been no amendment of the application subsequent to the final rejection dated 
March 20, 2008. 

Summary of Claimed Subject Matter (37 C.F.R. $ 41.37('c) (1) (v)) 

Without limiting the interpretation of claims in appellants’ application, which claims 
stand on their own, all claims relate to “proxy email” installations, methods or programming 
where a proxy entity receives email for customers, at customer proxy email addresses, then 
decides which, if any, email message to send to a customer in an email to the customer’s actual 
email address based on the customer’s previously expressed preferences. 

The independent claims involved in this appeal are 1, 2, 6 and 11. Again, without 
limiting the interpretation of the claims to the specific elements of any exemplary embodiment 
described in the specification, the following explains the claims' subject matter with reference to 
the specification and drawing figures. References in parentheses are to the drawing figure, page 
and line number of the appellants’ application as filed on February 28, 2005. 

Independent Claim 1 

The independent claim 1 is directed to a "proxy email computer installation" (block 60 in 
Fig. 3 or Fig. 7). The installation includes a database in computer memory (as indicated at 194 
in Fig. 8b) that associates a customer's identification (which can include the customer's personal 
contact information shown at 194 in Fig. 8b £uid as described, for example, at page 10, lines 4 - 
20). Also included in the proxy email computer installation is "an email server having an ability 
to receive a first email message at the customer's email address" (Fig. 9, block 136, page 10, 
lines 9 - 12). 

The proxy email computer installation of claim 1 has "computer executable code on a 
computer usable medium or media" (represented by the flow chart of Fig. 9, page 10, line 10). 
This code includes "(i) first programming to retrieve a customer's actual email address from the 
database upon receipt of the first email message to the customer's proxy email address" (block 
138 of Fig. 9, page 10, lines 10 - 13). The code also includes "(ii) second programming to 
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forward a second email message to the customer's actual email address, wherein the second 
email message is formed from the first email message" (Fig. 9, block 148 and page 10, lines 32 - 
34). 



The proxy email computer installation of claim 1 further includes "a connection to a 
communication link forwarding the second email message to the customer's actual email 
addresses" (the communication line 150 of Fig. 9, page 11, lines 1 and 2). 

Claims dependent from Claim 1 

Claims 1 5 - 1 8 are dependent claims depending from claim 1 directly or through mesne 
dependencies. 

Claim 1 5 provides that the email server of claim 1 "is set up to receive all incoming 
proxy emails to a common catch-all account" (page 10, lines 13 and 14). Claim 15 also provides 
that "the email computer installation further comprises an email address management system" 
(Fig. 7, block 60) "that periodically checks for new emails for any customer" (page 10, lines 15 - 
17). 



Claim 16, dependent from claim 15, provides that "the first programming to retrieve a 
customer's actual email address includes programming to check email addresses of all addressed 
and copied parties for a proxy email address being served by the proxy email server whenever a 
new email is found by the email address management system" (page 10, lines 21 - 23). 

Claim 17 is dependent from claim 16 and provides "the second programming comprises 
programming to copy the content of the first email message into the second email message, the 
second email message comprising an email message from the proxy computer installation to the 
customer at the customer's actual email address" (page 10, lines 32 - 34). 

Claim 1 8 depends from claim 1 7 and further provides "programming in computer 
executable code on a computer usable medium or media to effect deletion of an email once 
addresses of all addressed and copied parties have been checked for proxy email addresses of 
customers and any content has been copied to an email to the actual email addresses of any 
customers whose proxy email addresses have been found" (page 11, lines 2 and 3). 
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Independent Claim 2 

Independent method claim 2 claims a method of proxy email address management (Fig. 
9, specification p. 10, line 9 - p. 11 line 12). that includes (a) "associating a proxy email address 
with a customer having a customer's actual email address" (shown at 194, Fig. 8b). The method 
of claim 2 further includes (b) "receiving an email intended for the customer at the proxy email 
address" (indicated at 136 in the Fig. 9 flow chart, page 10, lines 9 and 10). Additionally, the 
claim 2 method includes (c) "forwarding the email to the customer's actual email address" (Fig. 
9, block si 48 and 150, page 10, line 32 - page 11, line 3). 

Claims Dependent from Claim 2 

Claims 3-5, 19 - 26 are dependent claims. These depend from claim 2 or from one or 
more claims dependent from claim 2. 

Claim 3 is dependent from claim 2. This claim provides that the method of claim 2 
further comprises (d) "recording the proxy email address in a database in association with the 
customer's actual email address" (indicated at 194 in Fig. 8b, page 9, lines 23 - 27), and (e) 
"looking up the customer's actual email address upon receiving the email at the proxy email 
address" (block 138 of Fig. 9, page 10, lines 23 - 24). 

Claim 4 is dependent from claim 3. It adds the step of "causing a Web page to be 
displayed that bears the proxy email address" (The “WHOIS,” Fig. 3, block 27, item 23, Fig. 10, 
page 7, lines 22 - 29, Fig. 8c, items 202 and 23, page 9, lines 27 - 31). 

Claim 5 is dependent from claim 3. Claim 5 further provides the steps of "receiving a 
second email from the customer" (Fig. 7, items 20, 132 and 60, page 9, lines 8-12) and 
"forwarding the second email to a third party identified by the customer" (Fig. 7, items 60, 1 30 
and 29, page 9, lines 8 - 12). 

Dependent claim 19 is dependent from independent claim 2. This claim provides 
"receiving all incoming proxy emails to a common catch-all account" (page 10, lines 13 and 14) 
and "periodically checking for new emails for any customer" (page 10, lines 15 - 17). 
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Dependent claim 20 depends from claim 19. Claim 20 provides that "periodically 
checking for new emails for any customer comprises checking addresses of all addressed and 
copied parties for a proxy email address associated with any customer whenever a new email is 
found" (Page 10, lines 32 - 34). 

Dependent claim 21 depends from claim 20. It calls for "forwarding the email to the 
customer's actual email address comprises copying the content of the email into a second email 
to the customer's actual email address" (page 10, lines 32 - 34). 

Dependent claim 22 is dependent from claim 21 and provides "deleting an email once 

addresses of all addressed and copied parties have been checked for proxy email addresses of 

*\ 

customers and the email has been copied to the actual email addresses of any customers whose 
proxy email addresses have been found" (page 11, lines 2 and 3). 

Claim 23 is dependent from independent claim 2 and adds the step of "receiving a non- 
email message sent to the customer at a location based on publicly available proxy contact 
information" (page 1 1 , lines 6-9). 

Claim 24, dependent from claim 23, further provides that "receiving non-email messages 
comprises receiving a message by ground carrier service" (page 1 1 , lines 6 - 9). 

Claim 25 is dependent from claim 23. This claim provides "alerting the customer to the 
receipt of the non-email message" (Fig. 13, page 11, lines 10 and 11). It also provides "affording 
the customer the opportunity to request receipt of the non-email message" (Fig. 13, item 214, 
page 1 1, lines 1 1 and 12) and "forwarding the non-email message to the customer if the customer 
requests receipt of the non-email message" (page 11, lines 4 and 5). 

Claim 26 is dependent from dependent claim 4. It provides that step (f) of claim 4 
comprises "saving the proxy email address into whois data for a domain name" (Fig. 7, items 24, 
27 and 60, page 9, lines 32 - 34). 

Independent Claim 6 

Independent claim 6 calls for a proxy email computer installation including "a database in 
computer memory storing customer information in association with a proxy email address, 
1933741 5 
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wherein the customer information includes a customer's actual email address" (indicated at 194 
in Fig. 8b, page 9, lines 23 - 27). The computer installation of claim 6 has "an email server to 
receive an email intended for a customer at the proxy email address" (Fig. 9, block 136, page 10, 
lines 9-12). The claim 6 installation includes "computer executable code on a computer-usable 
medium or media providing" (represented by the Fig. 9 flow chart, page 10, line 10) providing 
"first programming to detect the email received at the email server intended for the customer" 
(block 138 of Fig. 9, page 10, lines 12 - 13). The code also provides "second programming for 
retrieving the customer's actual email address from the database upon receipt of the email" 

(block 138 of Fig. 9, page 10, lines 23 - 24) and "third programming to forward the email to the 
customer's actual email address" (Fig. 7, items 20, 60 and 132, page 9, lines 2 - 4). The 
installation of claim 6 provides, as well, "a connection to a communication link for forwarding 
the email to the.customer's actual email address" (Fig. 7, link 132, page 9, lines 2 - 4). 

Claims Dependent from Claim 6 

Dependent claim 7 adds to the proxy email computer installation of claim 6 "a filtering 
software in computer-executable code on a computer-usable medium or media for preventing an 
objectionable email being forwarded to the customer" (Fig. 9, blocks 144, 146, page 10, lines 27 
- 32). 



Claim 8 depends from claim 7 and provides "in said database, an indication of customer's 
choice or choices for an email filtering" (page 9, lines 5 - 7). 

Claim 9, dependent from claim 8, provides for customer choices of; 

(i) no filtering; 

(ii) blocking all emails addressed to the proxy email address associated with 
the customer's information; and 

(iii) blocking objectionable emails addressed to the proxy email address 
associated with the customer's information 

(Fig. 9, decision blocks 140 and 144, page 10, lines 24 - 30). 

Claim 10 is dependent from claim 9 and provides that "the blocked objectionable email is 
selected from the group consisting of SPAM, bulk email, advertising, pornography and code to 
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interfere with a computer's workings" (Fig. 9, decision blocks 140 and 144, page 10, lines 24 - 
30). 

Independent Claim 1 1 

Claim 1 1 is independent. The claim is drawn to a computer program (the Fig. 9 flow 
chart) for proxy email address management (Fig. 7, block 60) that comprises computer- 
executable code on a computer usable medium or media (a) "first programming establishing a 
database for storing customer information in association with a proxy email address, wherein the 
customer information includes a customer's actual email address" (indicated at 194 in Fig. 8b, 
page 9, lines 23 - 27). The claim 1 1 program further includes (b) "second programming to 
identify a first email intended for a customer addressed to the proxy email address" (block 138 
of Fig. 9, page 10, lines 12 - 13). The claim also provides (c) "third programming to retrieve the 
customer's actual email address" (block 138 of Fig. 9, page 10, lines 23 - 24), (d) "fourth 
programming to copy content of the first email to a second email" (page 10, lines 32 - 34), and 
(e) "fifth programming operative to send the second email to the customer's actual email address" 
(Fig. 9, item 150 and page 10, line 32 - page 11, line 2). 

Claims Dependent from Claim 1 1 

Dependent claim 12 is dependent fi’om independent claim 1 1 and adds to the computer 
program of claim 1 1 "sixth programming to identify a third email from the customer" (Fig. 7, 
items 20, 132 and 60, page 9, lines 8-12) and "seventh programming for copying content of the 
third to a fourth email for the customer's intended recipient" (Fig. 7, items 60, 130 and 29, page 
9, lines 8-12). 

Dependent claim 13 depends from independent claim 1 1 and further comprises "sixth 
programming for filtering out objectionable emails" (Fig. 9, blocks 144, 146, page 10, lines 27 - 
32). 



Dependent claim 14 depends from claim 13 and further provides "seventh programming 
for receiving a customer's choice or choices of filtering and for storing the choice or choices in 
the database" (Fig. 12, page 9, line 5-7) and "eighth programming to recognize the customer's 
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choice or choices and filter or not filter emails to the customer based on the customer's choice or 
choices" (Fig. 9, blocks 144, 146, page 10 lines 24 - 32). 

Grounds of Rejection to be Reviewed on Appeal (37 C.F.R. § 41.37(c') (1~) (\\)) 

All of claims 1 - 26 stand rejected under 35 U.S.C. § 102(e) as anticipated by a published 
continuation-in-part U.S. patent application No. 2003/0191969A1 of Katsikas ("the Katsikas '969 
published CIP” or “CIP application"). That application is attached for the Board's convenience 
at Appendix D. 

Argument G7 C.F.R. S 41.37(cl m Tvim 

First, because those portions of the relied-upon Katsikas '969 published CIP that are 
entitled to a "prior art date" early enough to qualify as prior art as to the present application do 
not disclose the proxy email provisions of the rejected claims of this application, the rejection of 
all claims as anticipated by the '969 published CIP is in error and cannot stand. Second, cited 
portions of the predecessor applications fi'om which the Katsikas ‘969 published CIP claims 
priority do not supply the additional content needed to reject the claims as “anticipated.” Third, 
even taken in their totality, irrespective of the filing date to which they are entitled or whether the 
content can be considered as part of the published ‘969 CIP, the Katsikas published CIP and its 
predecessor applications do not have disclosure capable of anticipating the invention as claimed. 

Katsikas Briefly 

The Katsikas published CIP application, parent application and provisional application 
relate to computer software used by a “subscriber” for eliminating unwanted "spam" email. The 
software features of the Katsikas provisional, parent and CIP applications changed with each 
filing. For each application, however, incoming email is compared to an "authorized sender list" 
or " ASL" to determine whether to block incoming email from reaching its intended recipient. 
Content that the examiner quotes from the provisional application in support of the final rejection 
is not present in the published CIP application on which the rejection is based. The published 
CIP application introduces for the first time a processor called variously a "SkProxy Processor" 
202 (In Fig. 2), an "email proxy preprocessor" (paragraph 0027) or a "skproxy preprocessor" 
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(paragraph 0037). Prior to the filing of the CIP application, nothing described as a “proxy” had 
been disclosed. 

The Relevant Applications and Their Effective File Dates 

Filed March 31, 2003, the Katsikas '969 published CIP application is entitled to priority 
from parent application Serial No. 09/648,894 filed August 25, 2001 (the "parent '894 
application") only for subject matter common to the parent and this continuation-in-part 
application. Transco Products Inc. v. Performance Contracting, Inc., 38 F. 3d 551, 556-57, 32 
U.S.P.Q. 2d (BNA) 1077, 1080 (Fed. Cir. 1994). The parent '894 application of Katsikas claims 
priority from a provisional application Serial No. 60/180,937 (the '937 provisional) filed 
February 8, 2000. Subject matter from the Katsikas '969 published CIP application relied upon 
in and essential to the rejection under 35 U.S.C. § 102(e) was introduced upon the March 31, 
2003 filing of that continuation-in-part application. As to that content, the relied upon '969 
published CIP is not prior art as to this application on appeal which has a priority date of August 
30, 2002. Appellants’ August 30, 2002 priority date is the filing date of an international (PCT) 
application serial No. PCT/US02/27956. This application on appeal is a divisional of the 
international application’s U.S. National Stage Serial No. 10/624,883 (now U.S. patent No. 
7,130,878). Appellants’ priority and the lineage of this application is in the record at the 
application’s Cross Reference to Related Applications as amended February 28, 2005. 

The Basis of the Examiner's Rejection under 35 U.S.C. $ 102re) is in Error 

In a December 13, 2007 response to an Official Action applicants pointed out that the 
portions of the Katsikas '969 CIP relied upon in the rejection of the claims were not entitled to a 
date sufficiently early to qualify as prior art. In the subsequent, final Official Action of March 
20, 2008 the rejection was nevertheless maintained. There it was stated, incorrectly, that the 
subject matter not explicitly included in the prior PCT provisions and parent applications was 
present in software (called "SpamKapu software") that was said by the examiner to have been 
included in the provisional application. For the Board's convenience, a copy of the '937 
provisional and '894 parent applications are attached at Appendices E and F. The SpamKapu 
software is not itself included in the Katsikas '937 provisional, but rather, aspects of that 
software, as of the time of filing, are described and flow-charted. 
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"Proxy email" installations, methods and programming are the subject of each of the 
independent claims 1, 2, 6 and 1 1 in this application. The installation, method and programming 
for proxy email of all claims at issue relate to the operation of an entity established to receive 
email addressed to a "customer" at an email address other than the customer's actual email 
address, in order to keep from the customer such email as the customer does not want to receive. 

The Katsikas '969 published CIP application, parent '894 application, and '937 
provisional relate to gate keeping software that a subscriber can use to let pass to the subscriber 
email from a sender whose identification appears on an "approved sender list" ("ASL"). In 
support of the alleged anticipation by the Katsikas published CIP in the final rejection the 
examiner states, at page 3 of the final Official Action: 

As per claims 1,2,6 and 1 1 , Katsikas teaches a proxy email computer installation (par 
0105, 0107, 0109-0110) including: 

A database (fig 2, elements 204, 216) in computer memory associating a 
customer's identification, a customer actual email and a customer's proxy email address 
(fig 2 and 10-1 1; par 0092); an email server (102) ...; a computer executable code on a 
computer usable medium or media providing: first programming to retrieve a customer's 
actual email address ... (par 0092-0094); second programming to forward (redirector 
203) a second email message to the customer's actual email address; and a connection to 
a communication link forwarding (106) the second email message to the customer's 
actual email addresses (fig 1-2 and 10-11; par 0043-0045; 0092-0094 and 0100). 

As for the assertion "Katsikas teaches a proxy email computer installation," the 
paragraphs 0105, 0107, 0109 - 01 10 that the examiner cites in support are not available as prior 
art as to the claims of this application. Paragraphs 0105, 0107, 0109, - 01 10 were new matter 
when the Katsikas CIP application was filed on March 31, 2003. The Katsikas ‘969 published 
CIP application attached here as Appendix D has indicated the content introduced only as of the 
continuation-in-part. March 3 1 , 2003 filing date. 

The Katsikas ‘969 published CIP on which the examiner bases the rejection does refer to, 
for example, “a proxy preprocessor 202,” “proxy addresses,” and a “Skproxy Instantiation 
Table” at pars. 27, 37, 91 - 102 and 100-102 and in Figs. 2, 10 and 12, but only in the “new 
matter” parts of the CIP first introduced in the application on the March 31, 2003 CIP filing date. 

Concerning the individual Katsikas elements of the above-quoted statement in support of 
the rejection, elements 204 and 216 of Fig. 2 of the Katsikas ‘969 published CIP were present in 
1933741 10 
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the earlier filed Katsikas applications. However, elements 204 and 216 of Fig. 2, the "Spam 
Processor," and the “Other Data Sources,” do not related to a “database” to associate a 
customer's identification, actual email address and proxy email address as the examiner asserts. 
The function of Katsikas’ “spam processor” is at paragraph 37 of the ‘969 published CIP. 

The Redirector 203 sends a request for validation for the email from the Spam Processor 
204 which maintains the Spam Processing Database (SPDB) 205, including the 
Authorized Senders Rules List (ASL) 206. The SPDB Database and ASL Rules List are 
the heart of SPAMKAPU, as they contain the processing rules and lists of persons 
authorized to send email to the respective SUBSCRIBERS of the system. The Spam 
Processor 204 sends a response, either that the sender’s address on the email is not 
authorized on the ASL List, i.e., is a SPAMMER, or is authorized on the ASL rules list, 
i.e., is a FRIEND, or is not present at all on the ASL rules list, i.e. is a UNKNOWN. 

In other words the “Spam processor 204” is involved in communications from and to email 
senders who are possible spammers, not the subscribers (or “customers” as the claims put it) that 
are to be protected from spam. 

Similarly the element 216 of the Katsikas '969 published CIP that the examiner cites is 
described as containing data such as "header data from sent email and data from other data 
sources," (paragraph 0042). It was never, as is contended jn the examiner's rejection, said to be 
"associating a customer's identification, a customer actual email, and a customer's proxy email 
addresses." The examiner's mistaken characterization of the Katsikas '969 published CIP's 
content in this respect is a central flaw in the anticipation rejection of every claim in this 
application because each independent claim in the application includes claim content associating 
the proxy and “actual” email addresses of a customer. 

The further application figures. Figs. "10-1 1," and the paragraph, "par 0092," that the 
examiner cites as to the “database” were new matter in the Katsikas '969 published CIP upon 
filing. They are not entitled to the filing date of either of the earlier Katsikas '894 parent or '937 
provisional application. 

In the above-quoted segment of the examiner’s rejection the examiner correctly cites 
element 102 of Katsikas as an "email server." This does not alter the failure of the Katsikas 
published CIP to anticipate the claims however. 
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Paragraphs 0092 - 0094 are cited in the foregoing quote from the final rejection for 
teaching the claimed "code ... providing ... first programming to retrieve a customer's actual 
email address." But paragraphs 0092 to 0094 are new matter as to the Katsikas '969 CIP and 
unavailable to support the rejection. (That the cited paragraphs do not actually provide what is 
stated in the final Official Action is treated below.) 

"Figs. 1 and 2 and 10, 11" and paragraphs 0043 to 0045 and 0092 to 0094 and 0100 the 
examiner cites for a communication link (identified as 1 06) for sending a second email "to the 
customer's actual email address." Figs. 1 and 2 of the Katsikas ‘969 published CIP show nothing 
of the kind. Item 106 is a generalized indication of the internet in Figs. 1 and 2. In Figs, la and 
lb email is shown received from the internet 106. This is email for a subscriber or customer 
('969 published CIP paragraph 0028 as to Fig. 2a, paragraph 0030 as to Fig. lb). Mail is not 
shown being sent through the internet 106 to the subscriber or customer as contended by the 
examiner. Rather, the email shown being sent via the "customer email client 101," which is the 
internet service provider such as Outlook or Netscape, is being sent from, not to, the subscriber 
or customer (again, paragraphs 0028, 0030 of the '969 published CIP application). The Katsikas 
'969 CIP Fig. 2 shows subscriber or customer email client 101 sending the customer's email 
message via a SMTP send manager 214 and standard "SMTP Send process." There is no 
suggestion in any of this of sending a second email message to a customer's actual email address 
as alleged in the paragraph quoted above. 

Given the foregoing then, the rejection entirely misstates the operations described in the 
published CIP and by virtue of that the final rejection in this application is in error and should be 
overturned even before considering what if anything further from the preceding ‘894 parent and 
‘937 provisional can be relied upon to supplement the teaching of the ‘969 published CIP. 
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The Rejection's Flawed Grounds for Reiving on Non-Prior Art Subject Matter in the 
Continuation-in-Part 



To justify persisting in the original rejection of claims in this application as anticipated by 
the Katsikas '969 published CIP application, the examiner contends that the '937 provisional 
patent application from which the Katsikas '969 published CIP application claims priority 
contains subject matter that supports the new matter that was introduced into or teaches what is 
lacking from the relied upon CIP. This basis for maintaining the mistaken rejection over the 
published CIP errs in three ways. 

First, the ‘937 provisional application content that the examiner cites to justify the 
rejection based on of the Katsikas ‘969 published CIP was dropped from the Katsikas line of 
applications and never became a part of the published application entitled to the ‘937 provisional 
application filing date. Second, that part of the earlier ‘937 provisional application that the 
examiner cites does not actually teach, support, expand on or explain the relied-upon new matter 
provisions or needed or missing features of the '969 continuation-in-part published application 
and so cannot support the rejection. Third, and most important, even if the content of the 
provisional application referred to by the examiner were considered to be a part of the '969 
Katsikas published CIP application, the application still would not meet the terms of the rejected 
claims. 



At page 4 of the final Official Action, the examiner states in the Response to Arguments 
in the final rejection: 

Applicants argued that Katsikas does not qualify as prior art for this application 
because the provisional application "937" and the parent application "894" lack pertinent 
details such as proxy email as recited by Katsikas "969." 

Examiner submits that although Katsikas does not elaborate on email proxy, this 
feature is included in SpamKapu software (see pages 7-8 of "937"; fig. 1-8). 

The examiner then quotes from the '937 provisional application: 

As a server-side software package or online service SUBSCRIBERS are added 
to SpamKapu system. Each SUBSCRIBER is provided with a PSM, ASM, and UMM 
and an SKE. 
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The SUBSCRIBER changes appropriate setting on their email software to 
accomplish the following: 

Use current interact standards (currently POP3 or IMAP4) to retrieve mail from 
both the PSM and ASM. 

Redirect email sent to their current email address to their SKE instead OR set the 
email reply-to address to their SKE. Use the SMTP manager to handle the sending of all 
email. Any email sent to the SKE is processed by the redirector as described above. Any 
email sent by the SUBSCRIBER through the ASL manager (via the SMTP manager) 
and processed as described above. 

The user can retrieve email from the ASM at any time using Internet standards 
(currently POPS or IMAP4). The user can retrieve email from the PSM at any time using 
internet standards (currently POP3 or IMAP4) user other software that can delete, further 
filter, or altogether discard the contents. 

SUBSCRIBERS may interact with the UMM at any time. 

The above passage and other text of the ‘937 provisional uses acronyms unique to that 
application and others known in the art. POPS and IMAP4 are used in the art for known 
protocols. ASM is used to mean “authorized sender mailbox,” UMM is “user maintenance 
module,” SKE is “Spamkapu email address” and ASL is “authorized senders list.” The 
definition of PSM was not found. 



At page 5 of the final Official Action the examiner concludes: 

Examiner concludes that although some of the contents of the provisional 
application and the CIP are different, the features and elements needed to reject the 
present application are similar in both references. Therefore, Katsikas qualifies as 
prior art to reject the claims of the instant application. Accordingly, the rejection is 
maintained. 

Regarding availability as prior art of the Katsikas provisional application content that was 
not carried forward into the Katsikas publication, 35 U.S.C. § 102(e)(1) provides that "a person 
shall be entitled to a patent “unless -...(e) the invention was described in (1) an application for 
patent, published under section 1 22(b), by another filed in the United States before the invention 
by the application for patent,-...." 

The provisional application contents relied upon by the examiner in support of the 
Section 102(e)(1) rejection of the claims in the application were not "described in an application 
for patent, published under Section 122(b) ...." Those contents did not become a part of the 
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subsequently published '969 application. For that reasons it is submitted the ‘937 provisional 
application section relied upon by the examiner is not entitled to the "prior art date" afforded by 
102(e)(1) and does not therefore qualify to support the Section 102(e)(1) rejection by filling in 
crucial missing content of the Katsikas '969 published CIP. It is noted in passing that the 
Katsikas '969 published CIP application does not claim to incorporate the '937 provisional or the 
parent '894 application by reference. Further, nothing in 35 U.S.C. § 122(b) relating to 
publication of a pending application suggests that a preceding and unpublished provisional 
application's content should be considered to constitute any part of the application ultimately 
published under the provisions of that section. And Section 122(b)(2)(iii) indicates that a 
provisional application is not to be published under the publication provisions of 122(b). 

In the present case there is left as available prior art to support the section 102(e) 
rejection only that published content of the Katsikas '969 published CIP that was not new matter 
upon filing of the CIP. As established above, and apparently acknowledged by the examiner, 
that published CIP content does not meet the terms of the claims in this application. 

Even Combined, the Several Katsikas Applications Do Not Anticipate the Invention 

Claimed 



The above-noted second and third bases for error in the outstanding rejection are related. 
The provisional application content that the examiner cites does not relate to a proxy email 
installation method or programming such that it either (1) overcomes the published '969 
continuation-in-part application's failure in this respect or (2) teaches the features of the claimed 
invention such that an anticipation rejection would be proper if the provisional application's 
content were, in fact, prior art as respects the present application. 

It is well established that anticipation of a patent claim by a prior art reference requires 
that reference to "read on each limitation of the claim." Verdegual Bros. v. Union Oil Co. of 
Calif, 814F.2d 628, 631; 2USPQ2d 1051, 1053 (Fed. Cir. 1987). The Katsikas '969 published 
continuation-in-part application does not meet the terms of the claims of this application as the 
examiner acknowledges. However, neither do the contents of the '937 provisional upon which 
the examiner relies. 
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Each of the independent claims 1, 2, 6 and 1 1 sets forth an installation, method or 
program that includes or deals with a customer's "actual email address," and "a proxy email 
address." Neither the Katsikas provisional application nor the Katsikas parent application 
describes or utilizes two differing email addresses that can be considered to be an actual and a 
proxy email address. In each of the claims in this application, the proxy email address and the 
customer's actual email address are used in a fashion not contemplated by any of the Katsikas 
applications. Consider each independent claim in the application. Claim 1 calls for "a database 
in computer memory associating a customer's identification, a customer's actual email address 
and a customer's proxy email address." Claim 2 calls for "associating a proxy email address with 
a customer having a customer's actual email address." Claim 6 calls for "a database in computer 
memory storing customer information in association with a proxy email address, wherein the 
customer information includes a customer's actual email address." And claim 1 1 calls for "first 
programming establishing a database for storing customer information in association with a 
proxy email address, wherein the customer information includes a customer's actual email 
address." These provisions and their association are not found in the Katsikas '969 published 
CIP, '984 parent application or '937 provisional application. Consequently it cannot be said that 
the '937 provisional application overcomes the deficit of the Katsikas '969 published CIP in this 
respect. And it cannot be said that combined the Katsikas published CIP, parent and provisional 
applications have what is necessary to anticipate the independent claims 1, 2, 6 and 11. 

As for dependent claims in the application they patentably differ from the Katsikas 
applications on the basis of their dependencies, but they do not stand or fall with the independent 
parent claims 1,2,6 and 1 1 . 

Nowhere in the Katsikas applications are the recited features of claim 3 - the features of: 

(d) recording the proxy email address in a database in association with the 
customer’s actual email address; and 

(e) looking up the customer’s actual email address upon receiving the email 
at the proxy email address. 
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The examiner states at page 4 of the final Official Action: 

As per claims 3-5, Katsikas teaches recording proxy email address in a database . . . ; 
looking up customer’s actual email address; causing a web page to be displayed; 
receiving a second email from the customer; and forwarding the second to a third party 
identified by the customer (fig 1-2 and 10-11; par 0043-0045; 0092-0094 and 0100). 

Again as pointed out above, none of the Katsikas applications teach recording proxy email 
addresses in association with actual email addresses. And the cited provisions of the published 
‘969 CIP application, even the new matter provisions thereof relied on by the examiner, do not 
describe that or the looking up of the actual email address upon receiving email at a proxy email 
address. 

Likewise the Katsikas applications do not show “causing a Web page to be displayed that 
bears the proxy email address” as called for in claim 4 or “forwarding” a “second email” (from 
the customer) to a “third party identified by the customer.” See the preceding discussion of the 
receiving and sending of email via the internet 106 in the Katsikas application. 

Regarding the dependent claims 7 - 10, as discussed above, the Katsikas applications 
describe preventing email reaching a subscriber unless the sender is on an authorized sender’s 
list. Contrary to the examiner’s fiirther assertion at page 4 of the final Official Action regarding 
claims 7 - 10, 13 and 14, the Katsikas applications do not speak of “filtering software” (claim 7), 
a database “indication of customer’s choice” in filtering (claim 8), the three available choices of 
“no filtering,” “blocking all emails,” and “blocking objectionable emails” (claim 9), or the 
filtering choices of claim 10. 

With respect to the claims depending from claim 1 1, claim 12’s programming to identify 
a third email from the customer and for copying its content to a fourth email to the customer’s 
intended recipient is unlike anything in the email receiving and sending of the Katsikas 
applications. Pertinent here again is the discussion above respecting the error in the rejection of 
the independent claims in relation to email sent and received through the internet 106. There, the 
programming of claim 12 relating third and fourth emails to and from the customer is not to be 
found in the Katsikas applications. 
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As to claims 13 and 14, the preceding comments relating to claims 7 and 8 regarding 
“filtering” and “filtering choices” are pertinent. 

Dependent claim 15 sets forth additional details of the programming of the appellants’ 
software handling email for customers. The claim provides that “the email server is set up to 
receive all incoming proxy emails to a common catch-all account, and the email computer 
installation further comprises an email address management system that periodically checks for 
new emails for any customer.” No such feature is taught in any of the Katsikas applications. 

Dependent claims 16-18 include by their dependency the provisions of claim 1 5 and like 
claim 15 are not anticipated by any of the Katsikas applications’ teachings. These are patentable 
over the Katsikas published application and its predecessors for this reason as well as for the 
particular additional terms of these claims. 

Claim 19 is similar to claim 15, but dependent from claim 2. The claim patentably differs 
from the Katsikas applications for the reasons set forth above with respect to both claim 2 and 
claim 15. 

Claim 20 is dependent from claim 19. It is similar to dependent claim 16 and patentable 
over the Katsikas applications’ content for the reasons set forth above with respect to parent 
claims 2 and 19 and claim 16. 

Claim 21 depends from claim 20, has content similar to claim 17 and is patentable over 
the Katsikas application for the reasons stated in regard to claims 2, 20 and 17. 

Claim 22 depends form claim 21. It contains subject matter similar to claim 18 and 
patentably differs from the Katsikas application as discussed above with respect to claims 2, 21 
and 18. 



Claim 23 depends from claim 22. It patentably differs from the Katsikas applications as 
discussed respecting claims 2 and 22 and ftuther calls for “receiving a non-email message sent to 
the customer at a location based on publicly available proxy contact information.” This is not 
taught by Katsikas. 



1933741 



18 




Ally. Docket No. 15569-0007 



Claims 24 and 25 are dependent from claim 23 and patentable over Katsikas for all of the 
same reasons as claim 23. Additionally, unlike Katsikas, claim 24 calls for “receiving non-email 
messages comprises receiving a message by groimd carrier service,” and claim 25 calls for 
“alerting the customer to the receipt of the non-email message, affording the customer the 
opportimity to request receipt of the non-email message, and forwarding the non-email message 
to the customer if the customer requests receipt of the non-email message.” Claims 24 and 25 
patentably differ from the Katsikas applications by these recitations. 

Claim 26 is dependent from claim 4. It additionally recites “step (f) [of claim 26] 
comprises saving the proxy email address into whois data for a domain name.” The claim is 
patentable by its dependency from claim 4 and by its additional content absent from the Katsikas 
application. 

Conclusion 



For each of the above reasons, the final rejection of all of claims 1 - 26 as anticipated by 
the Katsikas ‘969 continuation-in-part application under 35 U.S.C. § 102(e)(1) is in error and 
should be reversed. Each of claims 1-26 should be held patentable and allowed at this time. 

Respectfully submitted, 

GALLAGHER & KENNEDY 




Date: December 5, 2008 By: Thomas D. MacBlain 

Reg. No. 24,583 
Attorney for Appellant 



Gallagher & Kennedy, P.A. 
2575 East Camelback Road 
Phoenix, AZ 85016-9225 
602-530-8088 
tdm@gknet.com 



1933741 



19 




Ally. Docket No. 15569-0007 



APPENDIX A 

Claims, 37 C.F.R. § 41.37(c) (1) (viii) 

1 . A proxy email computer installation including: 

(a) a database in computer memory associating a customer's identification, a 
customer's actual email address and a customer's proxy email address; 

(b) an email server having an ability to receive a first email message at the 
customer's proxy email address; 

(c) computer executable code on a computer usable medium or media 

providing: 

(i) first programming to retrieve a customer's actual email address 
from the database upon receipt of the first email message to the customer's proxy email address; 

(ii) second programming to forward a second email message to the 
customer's actual email address, wherein the second email message is formed from the first email 
message; and 

(d) a connection to a communication link forwarding the second email 
message to the customer's actual email addresses. 

2. A method of proxy email address management including: 

(a) associating a proxy email address with a customer having a customer's 
actual email address; 

(b) receiving an email intended for the customer at the proxy email address; 
and 

(c) forwarding the email to the customer's actual email address. 

3. The method according to claim 2, further comprising; 

(d recording the proxy email address in a database in association with the 
customer's actual email address; and 

(e) looking up the customer's actual email address upon receiving the email 
at the proxy email address. 
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4. The method according to claim 3, further comprising: 

(f) causing a Web page to be displayed that bears the proxy email address. 

5. The method according to claim 3, further comprising: 

(f) receiving a second email from the customer; and 

(g) forwarding the second email_to a third party identified by the customer. 

6. A proxy email computer installation including: 

(a) a database in computer memory storing customer information in 
association with a proxy email address, wherein the customer information includes a customer's 
actual email address; 

(b) an email server to receive an email intended for a customer at the proxy 

email address; 

(c) computer executable code on a computer-usable medium or media 

providing: 

(i) first programming to detect the email received at the email server 
intended for the customer; 

(ii) second programming for retrieving the customer's actual email 
address from the database upon receipt of the email; 

(iii) third programming to forward the email to the customer's actual 

email address; and 

(d) a connection to a communication link for forwarding the email to the 
customer's actual email address. 

7. The proxy email computer installation according to claim 6, further comprising: 

(e) a filtering software in computer-executable code on a computer-usable 
medium or media for preventing an objectionable email being forwarded to the customer. 

8. The proxy email computer installation according to claim 7, further comprising, 
in said database, an indication of customer's choice or choices for an email filtering. 

9. The proxy email computer installation according to claim 8, wherein the 
customer's choice or choices includes one of: 
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(i) no filtering; 

(ii) blocking all emails addressed to the proxy email address associated 
with the customer's information; and 

(iii) blocking objectionable emails addressed to the proxy email address 
associated with the customer's information. 

10. The proxy email computer installation according to claim 9, wherein the blocked 
objectionable email is selected from the group consisting of SPAM, bulk email, advertising, 
pornography and code to interfere with a computer's workings. 

11. A computer program for proxy email address management comprising in 
computer-executable code on a computer usable medium or media; 

(a) first programming establishing a database for storing customer 
information in association with a proxy email address, wherein the customer information 
includes a customer's actual email address; 

(b) second programming to identify a first email intended for a customer 
addressed to the proxy email address; 

(c) third programming to retrieve the customer's actual email address; 

(d) fourth programming to copy content of the first email to a second email; 
and 

(e) fifth programming operative to send the second email to the customer's 
actual email address. 

12. The computer program in a computer-executable code on a computer usable 
medium or media according to claim 1 1 , further comprising sixth programming to identify a 
third email fi’om the customer, and seventh programming for copying content of the third to a 
fourth email for the customer's intended recipient. 

13. The computer program in a computer-executable code on a computer usable 
medium or media according to claim 1 1 , further comprising sixth programming for filtering out 
objectionable emails. 
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14. The computer program in a computer-executable code on a computer usable 
medium or media according to claim 13, further comprising seventh programming for receiving 
a customer's choice or choices of filtering and for storing the choice or choices in the database, 
and eighth programming to recognize the customer's choice or choices and filter or not filter 
emails to the customer based on the customer's choice or choices. 

15. The proxy email computer installation according to claim 1, wherein the email 
server is set up to receive all incoming proxy emails to a common catch-all account, and the 
email computer installation further comprises an email address management system that 
periodically checks for new emails for any customer. 

1 6. The proxy email computer installation according to claim 1 5, wherein the first 
programming to retrieve a customer's actual email address includes programming to check email 
addresses of all addressed and copied parties for a proxy email address being served by the proxy 
email server whenever a new email is found by the email address management system. 

17. The proxy email computer installation according to claim 16, wherein the second 
programming comprises programming to copy the content of the first email message into the 
second email message, the second email message comprising an email message fi'om the proxy 
computer installation to the customer at the customer's actual email address. 

1 8. The proxy email computer installation according to claim 17, further comprising 
programming in computer executable code on a computer usable medium or media to effect 
deletion of an email once addresses of all addressed and copied parties have been checked for 
proxy email addresses of customers and any content has been copied to an email to the actual 
email addresses of any customers whose proxy email addresses have been found. 

1 9. The method of proxy email address management according to claim 2, further 
comprising receiving all incoming proxy emails to a common catch-all account, and periodically 
checking for new emails for any customer. 

20. The method of proxy email address management according to claim 19, wherein 
periodically checking for new emails for any customer comprises checking addresses of all 
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addressed and copied parties for a proxy email address associated with any customer whenever a 
new email is foimd. 

2 1 . The method of proxy email address management according to claim 20, wherein 
forwarding the email to the customer's actual email address comprises copying the content of the 
email into a second email to the customer's actual email address. 

22. The method of proxy email address management according to claim 21, further 
comprising deleting an email once addresses of all addressed and copied parties have been 
checked for proxy email addresses of customers and the email has been copied to the actual 
email addresses of any customers whose proxy email addresses have been found. 

23. The method of proxy email address management according to claim 2, further 
comprising receiving a non-email message sent to the customer at a location based on publicly 
available proxy contact information. 

24. The method of proxy emml address management according to claim 23, wherein 
receiving non-email messages comprises receiving a message by ground carrier service. 

25. The method of proxy email address management according to claim 23, further 
comprising alerting the customer to the receipt of the non-email message, affording the customer 
the opportunity to request receipt of the non-email message, and forwarding the non-email 
message to the customer if the customer requests receipt of the non-email message. 

26. The method according to claim 4, wherein step (f) comprises saving the proxy 
email address into whois data for a domain name. 
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APPENDIX B 

Evidence, 37 C.F.R. § 41.37(c) (1) (ix) 

No evidence was submitted pursuant to 37 C.F.R. § 1.130, 1.131 or 1.132 nor any other 
evidence entered by the examiner and relied upon by appellant in the appeal. 
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APPENDIX C 

Related Proceedings, 37 C.F.R. § 41 .37 (c) (1) (x) 

There are no decisions rendered by a court or the Board in any proceeding. 
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(57) ABSTRACT 

A system for eliminating unautbori 2 )ed email sent to a user 
on I network analyzes the sender address of inoamiog email 
and detennioes whether il Is to be rejected by reluming a 
staTxtard **do such useP* error code or acc^t^ depending 
upon executing ptoccssing rules and analyzing managed 
liks of authorized senders. This provides an advantage over 
existing anli-^am filtering systems by intercepting unau- 
thorized email before it reaches an existiog email server or 
client. The system rejects all email unless authorized by 
using a standard such usei^ error code, and by redirect- 
ing tbe unauthorized email back to the sender or to a sender 
evaluation site. An ASL module captures authorized sender 
addresses from the user's outgoing email and other sources 
in order to update “authorize senders'' lists. Tbe system 
may employ a WDM procedure that notifies senders of 
rejected email to go to a separate website and register as 
valid senders alter passiiig an interaction test that predudes 
automatic registration by a mechanical program. A destina- 
tion proxy email address prooeduro allows subscribers to use 
temporary proxy addresses fox receiving email expected 
from unknown sources and instantiates senders as autbo* 
rized upon receiving tbe expected email to the proxy 
addresses. The uoauthorlzz^d-email rqection component can 
be readily configured as a hardware or software apph'aixx 
in laodem with a conveniional email server, email 
gateway, or firewall to an intranet, or as a software exteosuxi 
to an existing firewall system. 
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SUBSCRIBER'S esd^ngi 
i SMJP moil sefverL 

Re/isect 
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FIG 9 



fvcvt| at< 

®oT 

Using FROM email address 



supplied, loop Oirough each fine 
of ihe A8L until mere is a pattern 
. match til Bug field 



902 

Once there is a pattern 
match, execute Die 
corxfltion based on the 
codelnOiistieM 



amalj pattafi 
|motn@cH9.tffi : 



Execute 



iMle^^agniexj^j^^ 






*p )Bolxom 



Cel Cowlltbn- 



condltlon 



ASL Table (example) 



[always 



(□f|n@home.rom 



activeranga 

(2/5/2P04. 

6/5/2004) 



-Get Action— I 



action tftrua 



I friend 



friend 



I before 
1(12/1/2003) 



friend 



[always 




903 

If the condition reuims TRUE, 
execute the action based on 
the code In this fioW and ©»U 
by ratumlog ih© value lhal 
was resulted from this action. 

If condition returns FALSE, 
continue looping through each 
•mail pattern. 



Comment 



[mend 



|emsl (SPAMMErT 



l*ro working with this businassperson 

oftiYfrpmFebSto JunaS 

After 12n/2003, 1 do not want 
messages from this address 



lemaiiomouier / 

ksPAMMER. 
[bladdistbd, 

i(3%domain% 
[%SENDER%, 



email we get trom aol gets send bach 
with an explanation _ 

-un a 3rd party software, mark as a 
spammer, send a standard message 
to the system's administrator, and 
mafk it as coning from spamkapu's 
adirdnistfalof 

my birthday (alls on 3/1 7. so irom 
3/14 to 3/20, ni let anyone pa^ 
hroiwh to wish me a ha "‘ ' “ 



. laik as spammer, seno Tvera s 
to contact usT message, return *No 
ich tjgar" arrof. Inittafiza WBM, 






Ex&oute 



condition syntax 



Condition Table (example) 

descilptlon code 



activer^qe i 



Bctiverange {low 
date, high date) 



runooda 



Iblackhoto 



true if today is within a range 



nincodB(fflename) 



blackholeO 



before (date) 



ra !BT. 1CT 3 



runs long and langlhy code 
Pfogram 



if today >= %1 and today 
<g%2 then retumftruo) 



3rd party software to check 
against a blackhole list 



true if today to loss than date 



exec(fHe.pf) 



exec(biackhoIe.exe) 



if today then 

| retumftrue) _ 



Action Table (example) 



action M 


symax 

emailCldenL file) 


return parmi as WentlflBf. gel 2nd parameter as a 
tnenams, translate and email It. 




erTormsfl0(idenl, file, 
enoroode) 


return p0fm1 as IdenWier, gat iihd paramwittr as a 
(il^iame. translate and return it as the error code 


external 


flxeoffile) 


execute 2nd parameter as an extamai 3rd p^rty 
software package and return its result as the — 


emaSftn 


amailtmolhBr (kient, 
filename, to. from) 


return parmi as idanllllef. got Znd paramwer a& 
filename of message text, send it as ah ema'il to 4th 
oarameter, arul use 3rd parameter as FROM 


friervi 


nsturnf SPAMMER) 


relum value os FRIEND, no panne reeded 


spammer 


retiimfSPAMMER) 


return value os SPAMi^R. no oarms needed 
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FIG 1 0B: 
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ShProxyemeB 
addresses as needed or 
iQi^estDd by various 
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email to SkPiDwysmsil 

oddroat 



1005 

SKPioxy rcoelvos hooming cm^ v«ii 
Die dcstinadort address aeltoSkPiuxy 
emol address previously rfvon out 



FIG IOC; 
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result 
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1006 

Kwiit8lo’‘a(Jdrws 
to bo sidscribcf's 
actual einali address 
as recorded bt 
piepiooesaor table 



1009 

Insert original 




1010 

Pass son troi 


^ fU WV«Vam 

b> user name 
for rolorenco 




toradbedor 
2 



1013 

Exarnlrte SKIT end compare the 
number of senders using tss proxy 
eoalr^ ttia maxlmuin sondare 
aaowBtiie set by tio eoer end braneti 
on (be rMUlt. 



1013 
I Create 
I InslanlbSon entry 

hSKrr 



toil 

Insert approprtale entry 
in ASU Ubifl M direct 
by action fieWa In STK 
tatde 



Number of instanliatad pnsdes^ 
~is less than owximxn sandefs 



-r^ber of existing hs&nliated proxies equate or exceeds maxbnum serxJefS aHowad- 
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SYSTEM FOR ELIMINATING UNAUTHORIZED 
ELECTRONIC MAIL 

[0001] This coolinuatioD-in-pait U^. patcm application 
claims the priority of U.S. patent application Scr. No. 
09/648^894, filed on Aug. 25, 2000, entitled ^'System for 
EHmiDating Unauthorized Electronic Mair, which claimed 
the priority of U.S. Provisional AppHcalibn No. 6 0ASQ.02S^ 
filed on Sep. 1, 1999, entitled “Unwanted Emairpilteriog 
Sysicm”, and U.S. Provisional Application No . 60/180 J>37j, 
filed on Feb. 8, 2000, emitled “Unwanted Email Filtering 
System'*, al! by the same inventor. 

HELD OF THE INVENTION 

[0002] This invention relates to a system for eliooinatiag 
unwanted email, and particulariy to one in which all email 
must be rocogoized as scul by an authorized sender in order 
to be accepted. 

BACKGROUND OF THE INVENTION 

[0003] Unwarned or imauthorlzed email is a significant 
bane for users on worldwide networks, such as the cunent 
public. Internet. Once a persoh’s email address becomes 
known to a network system, it can easily bo replicated in 
computerized lists and passed on electronically to an unlini’ 
tied number of parties who have not been authorized or 
invited to send email u) the user. Auser's electronic mailbox 
can become inundated with such unauthorized email Unau* 
thorized or unwanted emaD is referred to gcaerically In the 
industry by the term although the term is not 

intended to be associated with or to disparage the popular 
canned meat product sold under the trademark “Spam** by 
Hortnel Corp. The user may have an email address with a 
oomraercial information service provider (ISF) service 
which limits Ibc amount of email that can be accepted aodfor 
stored or which charges the user by the volume received. 
The user may also waste a significant amount of time 
opening and reviewing such unwanted email Unauthorized 
email may also be sent by unscrupulous persons who may 
enclose a virus or noxioussoftwaie agent in the email which 
can infect the user's computer system, or which can be used 
as an unauthorized point of entry into a local networic system 
that handles the user's email. 

[0004] Most, if not all of the current software to control 
the receipt of spam is based upon the use of idenUfyinig lists 
of known spam sources or senders (“^ammer^}. Such 
codveotional spam control software functions on the basis of 
receiving all email as authorized unless a sender b identified 
as being on the exclusion Ibt and the email can be filtered 
out. This approach is only as good as the identifying list and 
cannot guarantee that the user will not leccivo spam. Spam> 
mcr lists require frequent updating and must be dbtributed 
in a timely tnaooer to all subscribeis to the spam control 
software or service. Sqpbbiicatcd q>amniera fluently 
change their source Interact address, and can defeat attempts 
to keep exclusion lets cunenl They can also route the 
unwanted email through the Internet servers of other parties 
so as to disguise the source of the emails through inrmcuous 
or popularly recognized names. A user’s email address may 
also become knowo to large numbers of individuals in public 
chat rooms or on public bulletin boards. Unwanted email 
sent by individuals arc not tradred on spammer lists, because 
ibo sending of email by individuals b technically not jam- 
ming. 



SUMMARY OF THE INVENTION 

[0005] Accordingly, it b a principal object of the present 
invention to provide a spam control system that cannot be 
defeated by spammers who frequently chai^ their source 
addresses or dbguisc themselves by routing email through 
other servers, or by individuals who send email that ace not 
invited or authorized by the user. It b a particular object of 
the ioventioo that the system of the invention rejects all 
email as unauthorized unless the sender b rccogmzed as 
being on the user's acceptance list 



[0006] In accordance with the present invention, a system 
for Gliminatiug unauthorized email sent to a user on a 
network comprises: 

[0007] (a) an email client for allowing the user to 
receive email scot on the network addressed to a 
unique email address of the user, 

[0008] (b) an etnail-receiviog server connected 
between the network and the email dlent for receiv* 
ing email addressed to the unique email address of 
the user, 



[0009] (c) an unanthorized-email reject^ compOr» 
ncqt having^ authori^ senders listYASl^l pabd^ 
* TOuch mamUfttg emuiT addresses of^i^eES autho - 
Bza to send irM-whfirf.ln the unau> 

tho rizcd*emafi fciccdon compoaoent b operable wj^h 
TM c maii-rcociving server for intcitcnling ai^ 
Tt ^fccbng any ioconamg emall^di^essed to the email 
"Saaress or Ibe user. 

[0010] In a preferred embodimcnl the system's ASL mod- 
ule includes an ASL rules database for storing ASL rules lists 
of authorized sender addresses and associated processing 
rales for respective subscribers of the system, & spam 
processor ra^ulc for proccssuig the ASL rule Ibt for 
matches, and an ASL manager for creating, maiataining, and 
updating the ASL rule lists. A redirector module rqects 
email based on Che outcome of the spam processor module 
processing the sender's address against the ASL rule list. 
Email rejected by the redirector module b redirected to a 
web-bas^ messaging (WBM) website and a message b sent 
notifying the sender to vbit the WBM site and confinn that 
the sender b a legitimate sender of email to the iolcndcd 
recipient. If the sender logs on to confirm iheir status, the 
WBM component on the site executes an interaefion proce- 
dure which can only bo performed by a human, in order to 
ensure that the confirmation procedure b not performed by 
a mcohanicai program. The ASL manager maintains the ASL 
rale Ibis bas^ upon sender address data collected from 
various sonroes and analyses of various email usage factors, 
including sent email, received email, contaa fists main- 
tained by the user, user preforenoe inputs^ third party pro- 
grams, etc. 






[0011] The invemion abb encompasses associated meth- 
ods of performing the above functions, as well as related 
software conqre neats which enable these functions' vo be 
performedL 



[0012] Other objects^ features, and advantages of the 
present invention wifi be described in further detai] below, 
with reforence to the following drawings: 



BRIEF DESCRIPTION OF DRAWINGS 
[0013] FIG. lA b a block diagram illustrating a standard 
Internet email system using the conventional method for 
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O' 



fllierins en»il q»Jiimers (Prior Art), as ^pared lo 
FIG. IB vrbieb shows a conceptual overview of a system in 
aocordanoc wUh the prcscDl invention^ 

[0014] FIG. 2 is a process flow diagram for a prefcned 
cmboditncBt of tbc anti-spam sysium of Itc present inveo- 
tioa 

[0015] FIG. 3A is a block diagram illustrating a siaotod 
SMTP send email process (Prior Art), ^ compared to Fia 
3B which shows a modified send cmaU process used m the 
present invention. 

[0016] FIG. 4A is a block diagram ilhislraling a standard 
SMTP receive email process (Prior Art)» as compared to 
FIG. 4B which shows a modified receive email process used 
in the present inventioo. 

[0017] FIG. 5 is a process ftcjw diagram iUustrotii^ the 
operation of an anti-^amproocssiDg routine in the preferred 
embodiment of the iovention. 

roOlSl FIG. 6 is a process flow diagram flUistraling the 
detaUed operation of a \tfeb-Based Messenger ^M) tou- 
tine for tondling emaU iniliaUy rejected by tbc um-«pao) 
control. 

[0019] FIG. 7A is a block diagram illustrating a standard 
SMTP send-ieccjve email handling pioc^ (I^ 
eompsred to FIG. 7B which sbov« a modified Redirector 
piocess tor hindhiig received email. 

100201 FIGS. «A to 8D «e scbemiUc diagrams illustrat- 
L the structure and operation of the ASL Manager in the 
preferred embodiioent of the spam control system. 
r002tl FIG. 9 illosuatcs a detailed implemeotaTioii of 
examples of processing of emad send/re«ive and u«r 
contact data into ^ecifle forms of adions taken by Ibe ASL 
. Ma nager. 

[0022] FIGS. lOA to IOC arc sctemaifc diag^ms illuv 
irating the structure and operation of the inv^tion s cm 
proxy address subsystem proocssiqg in the preterteo 
cmbodHneoi of the spam conirol system. 

r0023l ncs. 11A and llB ffluslrate examples of the 
implernentatioa of ptoceasing rules and results associated 
with the enuil proxy processing subsystem. 

[0024] FIG, 12 illustrates a dciaiVcd implementation of 
how Ibc email proxy processing subsystem codvctIs or 
instanliaies incoming cmaU addresses that have rrol been 
previously received. 

[0025] FIGS. 13A to 13F are schematic diagrams illus- 
tratina how the invisaiion in its preferred embodimcol would 
be installed/configured in existing email server architcc- 



the unwanted croaU alter it has been ^picd. 
outright rejects the email at the esriicst entry Icvel^ 

. ««vei>.level “no such user rrmr iruiwsiTg 10 wP 
!^ice that isjcaaaniBaog ^ /V , 

■lOvcnUon operates on dw preroiic that all ^ 

Re fetek nt*s(u4r) ----« w.M cvnnhe 

■ Sorted. T his provides an mbetcuUy powerful and 
ett ' e^^ '^ani cootrol solution in an enviionment ^re 
spammers can iostantaneously change their s^rcc address 
or apparent identity and individuals m pubhc ^ 
obtain email addresses of other users and send them 
unwanted email. 

[0027] The following is a detailed description of om 
preferred embodiment of a system for implemeotii^ the 
fevention txioccpt. To this embodiment, the spam .^trol 
system mtelligeoUy formuJitcs the '■.auiborumd w^ets 
rules list based iifnn V;-7^flTHrf1 nTrvinn^lv stnrttfl. 

ra - _ — _ < An rhfllTT 



I lures. 



detailed description of INVEOTION 

r002«] In contrast to the known approaches of exisliOR 
spam conirol methods of accepting all email unless listed on 
an exdnsicn list as unauthorized, the fend^ntal principle 
of the present inventioo is to tejcca all email unlesa the rulM 
procesmng returns a favorable reqionsc. lo Ibis manner, it is 
possible to filter out email that comes from untew^izcd 
spammcis as well as individuals who send «n«>l «>« “ 
M^vited by the user. Unlike the known email flltcring 
systems, the present inventioo does not attompt lo filter out 



rules i»i oascu . ■■ — ^ 

tin the proxy preotocessgt. an ODbmmg analysia of the 

'•nsei‘s email sSlTtS whoiri and with what fte- 

Qucocy sent email is addressed lo other users, and Uirou^ 
the gathering ofhigh-level usereontaet dat8;such asa u^t s. 
lUMwo conlBCls'aod associates identified on other hsis ot 
files maintained by the user whi* indicate f 
eied as anlhorized. The “authorized senders juteg^ma 
also be updated and n«wiptUaied b^lhouset^^^ 
add or r emove authorized «nden.t.Wor as^Hwt^ process- 
ULa. tlili ■.pLLllil- implrmrmtitlnn 

-^^Crebmponents are provided and ^ 

iDiuopcTsbXclo the described ways, it is lo be understood 
that ^ toll scope of the invention Is deemed to encomp^ 
many other suitable modifiealions and yanaUons lo the 
dosaibed guiding principles of the invention. 

100281 FIG. lA is a block diagram of a standard cm»l 
system for sending and receiving email on the 
is used to ex^ain the conventional method for M«mg out 
cmafl ftom ^airunera. The system tofiows a 
try protocol for handling email on the Intemet. refeii^ to M 
SMTP. Dficis typically subscribe with a ctoen ISP for 
Internet acc^ and related services 
vices. The users access the Internet through the ISPusmg a 
■ti.fa p or high-speed line connection and a standardtoowset. 
The briiwser includes or functions with a stan^ e^ 
client 101, such as the Outlook TM eraa^ client ‘>^»*ut^ 
bv Microsoft Corp., bcidquaitetcd >n Bc^ue, “ 

the Netscape™ email client used by AOL Online, FiirfcW, 
Va Hie ISP operates at a wdasite address oorrc^odmg to 
to' domain name which is addressable by uscis on the 
InierneU TbeTSP's service fnnctioos are performed for a 
laiee number of snbscribciB through one or iMte servers. 
Typically, an email server 102 is used to handle the email 
s^ce toncUons. Email sent lo tbc ISP from the foteroel is 
received at SMTP Server 104, where various adnimislrative | 
tonctions are performed, 

addressee is an awthDrized subscriber of tire then the 
email is placed in a storage ^aoc reserved that u»r, 
refer f erfu) as Inbox 103. When users connect to the ISP. they 
can retrieve ibcir cnreil and store it wiih ihejr wo email 
client (on their own computer). Users can send emw y 
comtxjsing it locally at their email dictil, then uploadiog U 
to tlto SMTP Server 105 at the ISP. which then routes it to 
the recipient's email address on the Inieraet. 
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[00291 Conventional anti-spatn oootrol can be inylc- 
memcd with ihe SMTP Server and/or al the email cUem. 
Many ISPs iraplcmcot an tarclusion lisi of known jammers 
at ibe SMTP Server. In addition, they commonly allow a I 
user to filler onl unwanted email from certain senders known \ 
to the user. For example, U» user' s email dient rnay have a i 
filtering tunclioo that allows the user to input unwanted 
sender email addresses lo the SMTP Server so that email 
received by the SMTP Server can be filtered out before 
being pul into the user's Inbox, yurther, independent soft- 
ware vendors sell sophisticated email handling piograms 
chat work with ibe user's email client For ex^plc, some 
handling program have ftmedons tor categoriang icceivcd 
email into topical file folder^ and email ficom unrecognized 
senders may be pul into a “Miscellaneous'’ or “Unrccog- 
nined” file folder. 

[0030] In FIG. a conceptual overview of a system in 
accordance with the present iDVcnlion is diown. As before, 
the standard email cHcot 101 is connected lo an email server > 
102 for sending and receiving email to and from ihe Intemet 
via SMTP Server 1 04 and Inbox 103. How nyer^ in this 
modified j apd<ailUli, liiS' pifftsent luvennon proviilcs for anl 
' ^aul&oi^d'enuil rejection component 113 upstream of l 

i thc existing email server which inlcrcepls and rejects enreilr 
before it is — ^If f1 try 

exponent 113,^u Authbn^ Sender lislXASt} Manager 
TapiUi^^yiCT t addresses from email sent by Ihe 
user, as shown at block lU/and also captured sender email 
addresses from email sent io4he usccp as shown at block lO/ > 
The ASL Manager analyzes the captured sender email 
addresses and recipicnl email addresses and cn^loys oeftaln 
pre-defined rules (described in further detail bebw) lo add 
or remove email addresses firom Ibe “authorized senders 
listljc ferrcd lo as the A5jT List or DaUb^. Tbo ASL 

lid is used by ihc^^AMKAPU Server 113 to accept 
Jfbm'^fiQcro ihiSI favorably pass Ibe ASL pto- 
\ casing and subsequently relays the email to the prc-cxi^ing 
f Wndard SMTP email server 104 while rejecting all other 
5^ Email with a “not such usci^ cnor code, as indicated at blocl^ 
“ ■ 

[0031] Referring to FIG. 2, the process How fiw the 
operational steps of the anll-^am sy^em of the present 
invention will now be described. Certain terms used in the 
description are defined below: 

[0012] SPAMKAPU: An example of the spam conlrol 
system of the iDvcnlion. 

[0(03] SUBSCRIBER: A person subsenbiog co an ISP 
email service tbal is using the spam control system of 
the invention. 

[0094] FRIEND; An emai l-sending source that is autho- 
rized by the spam control system to send eipail to the 
SUBSCRIBER. 

[0035] SPAMMER; An emafl-sending source that is toI 
authorized to send email to the SUBSCRIBER, whi^ 
is commonly understood to be an unknowri or unau- 
thorized party that is using a manual or computerized 
email list mailing program to send large volumes of 
eroails-rcpetilively through the Intern et. 

^ "[oWel] UWi&J6^VN: An email sending source Ihaibasl 
not yet been identified as either a SPAMMER or aj 
CONTACT. I 



[00371 Email sent from the Inlemcl (lOfi) is sent lo the 
email address of the ISP for the SUBSCRIBER, referred to 
in Mock 201 as the SgaiqKapy .fapy] Adftress ftSKEj,,, 
deceived email must pass through the skproxy prepro- I 
[■ ccssor 202. The skProxy preprocessor examines the “to:'* J 
I email address against a table of proxy addresses and if there |l 
\ is a match ^ppronriatelv nipcesscs the cmal before passing J 
\ ii to the Redirector 209^c Redirector 203 sends a requ^ 
vahdahUU Ibt Uietm ail from the Spam Processor 2M 
which maintains the Spam Processing Database (SPDB) 

205, including the Authorised Senders Rules List (ASL) 

206. The SPDB Database and ASL Rules list ace the heart 
of SPAMKAPU, as they contain the processing rules and 
lists of persons authorized to send email to the rc^>cctivc 
SUBSCRIBERS of the system. The Sphm Processor 204 
sends a re^onsc, either that the sender's address on the 
email is not authorized on the ASL List, ix., is a SP/^- 
MER. or is authorized on A.«gT mlt y 1 ml i.e.. as ^ 

imt preseF Ts^ nn tn^^^nilcs lisL Lc.^7/ 
V*aUNXNO WN. i ffl^ lespons^ that it is a SPAMMER, the 
L^ctffl^c^TOTrejects the email, as shown at blodc 207 , such 
as by sending a standard error xncss^c to the senebng server 
that the user as addressed docs not exist. 

[0035] As a refinement lo the system, a Web-Bastd Mes- 
senger (WBM) process at blodc 208 may be set up to 
provide a corrective procure in the event that the 

in ffVili vet listed on il3e..^L ™ | 

TtEere forc an IJNKKQWf>Jl Thc unauthorized cmafl may 
who has not been previously 
prx>cesscd in the anti-spam system but who has a legitimate 
reason to reach the SUBSCRIBER. The WBM proc^ 208 
is set up as part of the sp ^ control sys tem to_whicii tbe_ 
mtc«ed email is redircctccLJbc WBM process then sends an \ 
whn fa DOW treated as an 

^ \ UNKNOWNy ^ example, the email message may rcao; 

[0039] '*An email sent by you to SUBSCRIBER'S 

( address was redirected to this site as being sent from 
an unrecognized sender address which may be a 
source of spam email. If you would like to oonfiiin 
yourself as a person with legitimate reason to reach - 
the SUBSCRIBER, please visit the WBM ate.jind - 
oonfiim your status as a FRIEND." 

[0040] The WRM P«Y-hV^ ° separate web site addn^ , 
for interactions wit hPjSK^ ai ^NKNO WNi | 

receives the error ib^pons^^manTif they arc a legltimalc 
FRIEND for the SUBSCRIBER, they may elccl lo go to the 
WBM sitcuo ooofirai their status as a legiiiinaie FRIEND. 

If done beflue the e:qriratioo dat<^ the WBM process will/ 
add an cmryil^gibe ASL rules list so the now validated F 
FRIEND mayro^cfidj^ previous cmafi an d ~ 

emails without corui albluiWlI lu UkicJi 30!#*. K' ifll*^USPECT 
does not respond, this fact is also sent to the ASL Manager 
for further analysis. The extra confirmation n\cp effectively 
eliminates SPAMMERS sinoe they use automated programs 
to send out batch email and typically will not talre human 
response lime to log on lo the AVBM site lo confirm their 
legitimate status. 

[0041] If the Spam Piocesror sends a validation response 

that the sender i ^FRlEN P- ilien the Re»tir^ctP^ 

the email lo tbc^cSgqat^ cxisitfigSMTP5rtver211 wbii^ 

f prOdCUUS Ibe'^mail accordance with erisling Imemet stan- 
dards fRFC82lV The user can now collect their email their . 
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siandard Inbox 212 (using standard laternal protocols such 
as POP3 or IMAP4) ibrougb the user email client 101 on 
their computer Tbeir email is 100% spam-fircc, since all 
email from senders not recognized by the system as autbo- 
riz ed has been rejected. ^ 

[0042] Users send email composed on and sent &ooa the 
email client 101 via standard SMTP protocols to the ISP's 
email server. The ISP*s SMTP server is responsible for 
providing users with email addresses witbin (be QStem, and 
sending users' email to the recipients* email addresses on 
the Internet 103. In tbo SPAMKAPU iaventioa ^icm, an 
SMTP Send Manager 214 is provided to intervene In the 
usual send email process. The SMTP Send Manager 212 
copies header informalion from all outgoing email and sends 
the dala to tbe ASL Manager 213, then sends the email oa 
to the ISP's eTdsting SMTP server which in-tum sends the 
mail to its intended destination as shown in block 215. The 
ASL Manager 213 performs one of the key fanctions in the 
invention system. It analyzes the header data from sent emaO 
and dala from other datasonroes 215 maintained by the ISP 
email server system, sudi as email logs and uscr-oupplicd 
lists. On the basis of its analysis routines (to be described in 
further detail below), the ASL Manager 211 checks, popu- 
lates, and updates the SPDB Database and ASL Rule List 
with the email addresses and other data on senders autho- 
rized to send email to the SUBSCRIBERS. The SPAM- 



KAPU system also includes User Maimenance Modules 
(UMM) 217 which allows the user to intcrtct with and 
upload user information to SPAMKAPU for further cus- 
lomization of SPAMKAPU's email operations for the user. 



[0043] Referring to FIGS. 3A and 3B, a standard SMTP 
send email process (Prior Art) is shown comjared to a 
modified send email process used in the present invention. 
Id the standard send email process, in FIG. 3A, email sent 
from the user's email cheat to the ISP's email server may be 
pre-processed, such as checking for correct syntax, alias 
expansion, etc., and to identify the list of rscipicol email 
addresses (could be 1 or more). The server email manager 
gets cadi icc^ient email address in turn a nd a ttempts to 
establish a connection to tbe destination SMTP server and 
verify if the redpient email address is proper. If negotiation 
i$ unsuccessful, an error message is returned to the sending 
SMTP sdver. If negotiation is successful, the sending server 
sends the message body to the destination server and per- 
forms 8 proper ''close oonncctioo'' operation. In the modified 
send email process of the invention, in FIG. 3B, the email 
sent from the client is prc-piocesscd by the SPAMKAPU 
SMTP Send manager 214 which copies the all redpient 
email addressfes) including but oo( b'mited to the *TX): CC: 
and BCC:** addresses and sendh the data to the ASL Manager 
213. The SPAM3CAPU SMTP Send Manager then passes the 
email to the existing ISP email server for transmiadon to the 
actual destioatioofs). On the assumption that the SUB- 
SCRIBER authorizes email to be received firom any person 
tho SUBSCRIBER has sent emaO to, the proper email 
oddresses of persons to wbom the SU^CRlBER has sent 
email ore added to tbe ASL list of persons autbonzed to send 
email to the SUBSCRIBER. Tbe sent email data can be used 
in further analyses by the ASL Manager, c.g., to upgrade a 
person's authorized status from temporary to permanent if 
more than a threshold number of email Is sent by (he 
SUBSCRIBER to tbe same person. 



[0044] Referring to FfG^ 4A and 4B, a sUndaid SMTP 
lecotve email process (Prior Art) is shown compared to a 
modified receive email. process used in the present invent 
tioo. In the standard receive email process, in FIG. 4A, 
email is received by the SMTP server from wndcr sources 
oo the Internet and the server stores the email in the user's 
Inbox. In the modified receive email process of the inven-. 
lion, in FIG. 4B, the received email is subject^ to process- 
ing by the slqpxoxy and redirector as shown in blocks 202 
through 206 to dctcrmioc (he nature of the sender's address 
(FRIEND, SPAMMER, or UNKNOWN). Even though the 
sender is already on the ASL authorized peckms list, the 
received email data can be used id further analyses by the 
ASL Manager, c.g., to upgrade a person's authorized status 
from tcaqjorary to permanent if email from that peisoo is 
received on an oogping basis and has not been changed by 
the user. The SMTP receive email process then sends tbe 
email to the existing SMTP sender via standard (rfc823) 
relay protocols for normal proccssing. 

[0045] In FIG. 5, n process flow diagram illustrates the 
QperatiOD trf tbe Spam Processor 203. At blo^ 501, a request 
from the calling routine, here Redirector 203, seeks vaUda- 
. tion whether a received email is from an authorized sender. 
The request identifies the parameters who the email is 
FROM and who il is sent TO. Tbe Spam Processor 204 uses 
the TO address to lookup that user's ASL list 206 in the 
SPDB Database 205, as lodicated at block 502. The lookup 
procedure fbUcFws a loop 503 of reading the next ASL record 
on the user's ASL list, cbeddng for a match to the email 
FROM address (authorized person), reading the next record 
if there is no match of the current rcconi, executing the 
match condition by issuing a TRUE value if found, other- 
wise returning for the next record, as intficated at block 504. 
At block 505, if a TRUE VALUE is issucxl, then at bk)ck 505 
the action is taken of executing the processes as defined in 
the Spam Processing Database or SPDB for this particular 
FROM/TO combination. Examples of processes include 
seltiiig the ouipui vahie lo cither FRIEND, SPAMMER, or 
UNKNOWN but also may indude the execution of 3*** party 
software that may determine a FROM source is bladdisied 
or even dclermiiung that the email contains viruses. At btodc 
506, the returned value is sent as a message to tbe calling 
routine. i.c., ibc Redirector 203. If the rclurocd value is 
UNKNOWN, a standard error message is included. As a 
default option, if no ASL list is found for the user, the system 
returns the value FRIEND, as indicated at block 507, in 
order to allow the email to be accepted as a temporary 
condilion until an ASL list can be established for that user. 
The request processing roulinc can be implemented using 
industry staodaid PERL programming syntax and incorpo- 
luHog a PERL intciprcter to execute the processing roles. 

[0046] In FIG. 6, a process flow diagram Uhistratcs tbe 
detailed operation of the Web-Based Messenger (W6M) 
roudoe for handling email rejected by the Redirector 202 
(see FIG. 2). Preferably, the WBM prcxxss is implemented 
via interaction with a rcjccUsd sender at a separate Web site 
address. In Phase 1, corresponding to stop 204 in FIG. 2, the 
WBM process is initialized at block 601 by the ASL rule 
rclnmiog a value tor rejecting an email as sent from an 
UNKNOWN by the Redirector 203. At block 602, a unique 
ID number is assigned to tbe UNKNOWN sender's email 
address in the WBM database and a given expiration dale is 
set, o.g., 48 hours. At block 603, a return email is sent back 
to the sender's email address in order to notify the 
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UNKNOWN to go to the WBM web page if they wish to 
follow through with cootactiog tbc SUBSCRIBER. The 
WBM then waits for the UNKNOWN to go to the WBM site 
to oomplete ibo process, referred to as Phase 2. At block 604, 
the UNKNOWN accesses the WBM web site and agrees to 
(he displayed terms and oondidons of usage. At block 60S, 
the WBM process verifies that the time for refuse for the 
email corresponding to the ID number has not expired. The 
WBM then follows a lest procedure to ensure that the 
responding UNKNOWN is not being implemeDtcd by a 
me^txical program. For example, at block 606, a word or 
question stylized in non-standa^ font can be di^layed as a 
graphic image, and at block 607 the SPAMMER is prompted 
to type the word or answer the question that appears in the 
graphic. A mechanical prograin would not be ^lo to read a 
graphic image of a word in unrecognizable font or would not 
be able lo answer the question. At block 608, if the WBM 
process determines that a correct word or answer has been 
typed, the UNKNOWN status is upgraded lo FRIEND on 
the user’s ASL Rule list At block 609, the WBM process 
notifies the FRIEND that he/she may rc-send Ibeir original 
email and/or other email to the SUBSCRIBER. At block 
612, if the SUBSCRIBER determines that tbc email is from 
someone whose email should be rejected without a WBM 
error reply option, the SUBSCRIBER may optionally down- 
grade the status pennanemly to SPAMMER through tbc 
UMM 214. 

[0047] Referring to FIG. 7A, a block diagram illustrates a 
standard SMIP scnd-icccivc email handling process (Prior 
Art), as conopared to FIG. 7B which shows a modified 
Redirector process lor handJing received cmaD. In the stan- 
dard process, the Scndei-SMTP 701 requests connection to 
the Receiver^SMlT 702, which accepts the conocctioo if 
available. The Sender SMTP then peifonns the task in its 
Send Email loop of sending the recipient’s email address. At 
block 703, (be Reedver^SMTP confirnos or denies whether 
the rodpicoi exists ox whether it has auihority to process 
email for this user. If confirmed, (he Sender-SMIP sends the 
message body and marks the end of the message. At block 
704, the Rcocivcr-SMTP receives the message body and 
sends it to (be email box of the recipicnl (or redpienta if tbc 
message is sent to more than one recipient at that SMTP 
server address. 

[0048] In HG, 7B, the Scndcr-SMTF 701 and Receiver- 
SMTP 702 perfonn their usual establishing of a connection 
and ditck for valid recipient e-mail address. However, in 
this modified process implemented in conjunction with the 
Spam Processor 705, the sender’s email header information, 
including the FROM address is stored by tbc Spam Proces- 
sor for later use, as Indicated at block 706. At block 707, tbc 
sender's PROM address and tbc ledpicm’s TO address are 
sent to the Spam Processor 70S, by a request for validation 
by the Redirector as described previously. At block 708, 
after checking the recipient’s ASL Rules list to determine the 
status of the sender, the Spam Processor caa return a 
refuse of FRIEND or a response of SPAMMER or 
UNKNOWN with an accompanying error message. If the 
rc^Dse is FRIEND, an output is scot to the Sender-SMTP 
confinning that the email can be received, and the email is 
sent to the Recelver-SMTP as usual. At block 709, the 
Reocivcr-SMIP relays the cinait to the recipieors gTnafl 
server for standard inbox ptoccssiog and, if desired, can 
include a ntessago noting t^t the sender was identified on 
the ASL list as a FRIEND. If the repose is SPAMMER. 



then an error message is returned to tbc Scoder-SMTP that 
the recipient does not exist or the Recipienl-SMTP is not 
authorized to accept the email. If the response is 
UNKNOWN, the Reoeiver-SMTP may send the email 
through the WBM process, as described previously (indi- 
cated at block 710). if the response from the Spam Processor 
indicales that the status of the sender is an UNKNOWN 
sender (as opposed to having the confirmed status of SPAM- 
MER). 

[0049] la FIG. 8A, a schematic diagram illustrates the 
structure and operation of the ASL Manager, previously 
described as oomponent 211 with respect to FIG. 2. The 
ASL Mnnagor preferably b structux^ to have an ASL 
On-Dcraand Processor 801 and an ASL Scheduler Prooeasor 
802, both of which utilize indu^ standard XML and Web 
service protocols to interaa with an ASL Rules Processor 
806, which also exchanges data with the Spam Processor 
Database (SFDB} 205. Email addresses sent to and received 
from the SMTP Send Manager 214 and SMTP Receive 
Manager 211 are processed by the ASL On-Demand Rx>- 
oessor 801 which executes Che appropriate rules in conjunc- 
tion with the ASL Rules Processor 803. G>ntont from a 
variety of other sources, including compatible third party 
plug-ins, can also be processed to create, populate, aod 
update the ASL lists stored in the SPDB 205; For example, 
couteat may be received from a '*Drag and Drop Manager” 
for conveniently baodliog user address inputs while working 
with the email client, user address inputs from Web sites 
while working with on. associated browser, addresses added 
by the user to a desktop contact manager, such as the 
Micxrosofi Outlook TM Address Book, or other contact lists, 
and other address inputs generated by third party software 
that can operate with the user’s etient programs. 

[0050] The ASL Scheduler Processor 80(2 is used to pro- 
cess tasks on a scheduled basis for various analysis and 
maintenance functions. This allows a very rich examination 
of (he SUBSCRIBER’S ASL list, mail log, and other data 
files, to continually refine the ’‘anthorized scndeis” list for 
accuracy and relevance. For example, the processor func- 
tions can meinde: an ASL Mail Log Analyzer lor analyzing 
the ASL Mad Log database 804 of the SUBSCRIBER’S 
received and sent emails; an Expiration Date Analyzer for 
setting and enforcing expiratioa dates for authorized senders 
to be re-authorized; a Low \blume Analyzer for downgrad- 
ing or eliminatii^ the authorization status of senders with 
whom the SUBSCRIBER oommumcates very, infrequently; 
a High \bhime Analyzer for upgrading or permaoently 
marking the authorization status of senders with whom the 
SUBSCRIBER communicates very frequently; a Fuzzy 
Logic Analyzer for making qualitative dedsions as to 
FRIEND or SPAMMER Status based on a varieiy of fiiciois; 
and other Third Party Analyzers for analyzing data gener- 
ated by third party plug-ins and programs to refine the ASL 
list. 

[0051] The ASL Rules Processor 806 contains the rules (in 
an ASL Manager Rules Database 803) (bat delennine how to 
add, update or modify the ASL lists matotnined in the SPDB 
Database 21^. The Rules Processor can have an architecture 
that readily accepts and interoperates wilb third parly data- 
bases 805 ud applications programs 807 in order to harness 
the collective power of devclopcjs in tbc actwork commu- 
nications industry to continually improve and extend tbc 
SPAMKAPU sysicm’s feature scL The uUfanaic result of this 
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aicbitBCturc is to enable ihc creation of a very richly detailed 
ASL database which goes beyond even the total climinatioa 
of spam email into other or future needs of users for the 
dynamic and intelligent handling of email. 

[0052] FIGS. SB, 8C, 8D, illuslrate various conhguraliona 
where the iavooUon intcr&ces with 3'^ parly services and 
software. FIG, 8B iUusiraies a specific example of how the 
cn-demand processor operates. In this case, 3*** party soft- 
ware inslallctl on the subscriber’s dient oomputor 810 
gathers all email addresses stored in an application such as 
Microsoft Outlook, then oonnccis to the spamKapu server 
using an XML interface 811 and uploads the contacts into 
the ASL Rules database 812* marking tiiem as ^Fiiend” . 

[0053] FIG. SC lUustratcs a ^>ecific example of bow the 
ASL Scheduled Processor invokes an XML interface 811 to 
connect to a remote 3’** party service 815 to perform a 
detailed analysis of the ASL Rules database. Updates to the 
database are traosmiltcd back by XML interface 815 to 
update the ASL Rules database 812. 

[0054] FIG. 8D illustrates a specific example of how the 
ASL Rules database can utilize a 3"* party to analyze email 
in real-time. As email is received by tbc SpamKapu server 
818 an ASL Rule is invoked to used a 3"^ party 819 and uses 
an XML interface 811 to connect to a party rcal-ame 
email analysis service 821 which may employ sophisticated 
pattern matchup analysis, for example. Tbc service 821 uses 
an XML interface 811 lo return a result of SPAMMER, 
FRIEND, or UNKNOWN 823 which is then further pro- 
cessed by the SPAM PROCESSOR 204. 

[0055] In FIG. 9, a detailed implementation is illustrated 
of examples of processing of email send/receivc and user 
contact data into specific forms of actions taken by the ASL 
Manager. Tbc basic process How constsb of; Step 901 of 
kx>ping through each line of an ASL rules list (called a 
Table) comparing the FROM address captured from an 
incoming email for a match; Step 902 of determining 
whatever conditioa or status fiag has been set for tbc 
matched entry, then exeonting the oortespoading condition 
rule 05 maintained oo the Condilioo Ihble, resulting in return 
of a Return Value; and Step 903, based on tbc Return Value, 
executing the corresponding action rule as maintaiDcd on the 
Action Table, and exiting with a Roal Return Value fiora 
this action. To follow one example through (bis process flow, 
Step 901 finds a FROM matdi of the sender addxeas 
jobn@bomc.coiD, Step 902 notes the expiration date condi- 
tion **befoie Dec. 1, 2003” and executes the “before” con- 
dilion on the Condition Table to return a value of “True” if 
today's date is less ihao the indicated expiration dale, and 
Step 903 notes that the sender status actioa (if condition is 
True) is “friend” and executes the **£riezid” action on the 
Action Table to retnro a Final Return Value of FRIEND (no 
parameters needed) as the validation response of tbe Spam 
Processor. 

/ [005Q The specific programming syntax or execution 

logic of the ASL Manager rules processing may be varied in 
any suitable manner dr^nding on tbe developer of the 
Spam Processor application. Tbc fbHowing examples of 
some options for ASL Manager actions illustrate a wide 
range of approaches that may be used: 



[0057] MATCHING AN EMAIL ADDRESS OR 
address PATTERN: 

[0058] (a) Default: exact match 

[0059] (b) A specific email address: 

john@corapany.oom 

[0060] (c) UNIX Siandard wfidcard matching: 

[0051] ♦.microsoft.oom-anything from 

“Microsoft.com" 

[0052] microsofl^«anything with roiciosoft in it 
[0063] “.mil-aoy email from the military 

[0064] (d) Matching any known “blackbole lisT 
by using a %BLAGKHOL£% symbol. 

[0065] USING A CONDITIONAL AND PARAM- 
ETERS TO EXECUTE IF THE MATCH IS TRUE 

[0066] USING A SECONDARY ACTION AND 
parameters to perform IF THE CONDI- 
TIONAL IS TRUE. 

[0067] USING THE LAST DATE THE SUB- 
SCRIBER SENT EMAIL TO THIS ADDRESS 

[0068] USING THE LAST DATE THIS ADDRESS 
SENT EMAIL TO THE SUBSCRIBER 

[0069] USING DATE THE RECORD WAS CRE- 
ATED 

[0070] EXAMPLES OF CONDITIONALS THAT 
CAN BE USED 

[D071] (a) Expn^tion dales; use a given address 
until Feb, 12, 2004 

[0072] (b) Date ranges: use a given address fitoro 
Apr. 1, 3004 to May 2, 2004 

[0073] (c) Specific recurring times: week of 

every month but no other time, e.g.^ 
acwslcU 6 i@maga 7 Jac.con 1 acceptable during 
week of each momh. 

[0074] (d) A link lo external software designed lo 
allow for additional user-defined criteria; this 
allows for Ibiid party applications 

[0075] EXAMPLES OF MESSAGES THAT MAY 
BE INVOKED BY A GIVEN SECONDARY 
ACTION 

[0076] (a) Standard ’‘crrai” 

[0077] (b) Custom with variable substitution in the 
message body, c.g.: 

[0078] %useniamc4b is substituted with the 
sender's email address 

[0079] 9^Kubid% is the ID code of ibe subscriber 
[0080] %daic% is today's date 

[0081] (c) “hello %uscraamc% you have been 
identified as spam, go to http://wwwspamkapu- 
xoTi/subscribeTo%subid% and if you're leaDy 
human weT let you in. 

[0082] (d) Qistom text: “All email addresses from 
Amelin O nlin e arc unconditionally rejected” 
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[0083] (e) Send a given osessage in the enor 
repose. 

[0084] (Q Send a giveo message as an email. 

[008s] (g) Open a file and email its contents 

[0084] (b) Open a file and send its oootents as an 
error reponse. 

[0087] (O Set the scadcr*ssUUis to SPAMMER or 
FRIEND 

[0088] (j) Oeale a unique ID that will expire after 
a short time period (24-48 hrs). This id can be used 
by the SUSPECT to access the WBM and become 
a COKIACT. 

[0089] (k) Give SMTP default error message 

[0090] (1) Link and execute cxtennal software 
designed to allow for additional user-defined 
actions; this allows for thiid party appUcations. 

[0091] Id FIGS; IQA and lOB, a schematic diagram 
Olustrates the stcuctuie and operation of the SkProxy email 
preprocessor. The preprocessor simplifies the method by 
which users can manage their ASL rules list in situations 
where the user may wish to receive email &om source whose 
“FROMr email address is not known. Examples of such 
include subscription to oewslcttecs where one supplies their 
email address to a newsletter service without knowing the 
coned “FROM" address until the newsletter is actually 
received* and online oidcrizig procedures that request a user 
email address for the purposes of semfing a confirmation 
email but do not disclose ihcir **FROM" email address. Tbc 
preprocessor is an additional software module that is 
designed Co reside on the same server as the other SpamKapu 
software. All tneoming email is first processed by the 
SkProxy processor and then passed on to other SpamKapu 
software modules as warranted. 

[0092] FIG. LOA illustrates the first plmsc of the general 
Skftoxy process whereby in step 1001 a user uses a standard 
Web browser to coonect to the SpamKapu server^ then 
requests and is given a list of “Proxy" email address which 
do not diiectly disclose or identify the user's actual teal 
email address step 1002. As an alteniative, the user may also 
first create their own proxy email address, tbeo enter that 
address into the SKT (FIG, llA) via a Web ioterfiice. This 
liberates the end-user from having to obtain email addresses 
beforebaod. These Proxy email addresses along with ihcir 
charactcrisltcs are stored in a table shown in FIG, UA. 
tiereinaftcr referred to as the “SKT*. 

[0093] lo the second phase shown in FIG. IW the end- 
user gives out these Proxy email addresses step 1003 as 
needed to subscribe to newsletters or other shuatioos where 
the “FROM;** email address is not known. When the entity 
that has received this proxy email address wants to send an 
email to the end-user, they can only send it to the proxy 
email addbess step 1004bccause that is the only address they 
have on file. The SkProxy process is the first to receive the 
email in Step 1005. 

[0094] Control is then passed to FIG, IOC, step 1007, 
decide if the proxy address has boeo instantiated or not by 
examining the SkProxy Instaoliation Table, described in 
FIG. UB and btreinafter referred to as the SKIT, and use the 
proxy and sender addresses to find a maufii in the SKIT. If 



an entry does not exist (meaning that it has not been 
instaotialcd), then in step 1013, SkProxy counts the number 
of number of senders using this proxy address by examining 
the SKIT and dclcnninc if the number of inslandaiions has 
reached the maximum allowed as defined by the user in the 
SKT. If the maximum h^ not been reach^ it insuntiaics 
the proxy address by creating an entry in the SKIT, as 
detailed in FIG. 12 and step 1012. Iii Step 1011, it references 
the entries in the SKT table along wilb the senders FROM 
address to create a ppropriate entries in the ASL Rules list as 
detailed in FIG. 12. In Step 1008, it rcwnies and updates the 
“TO;" address to be the actual address of tbc end-user and 
m Step 1009 adds the proxy email address in the end-user 
name area so that tbc end-user can see what proxy email 
address was used by the seodet. Step 1010 passes control U> 
the Redirector which may now properly evaluate the From/ 
To: oombioatioo and perform the correct processing. The 
email will now be accepted by the SpamKapu server 
because the instantiation process has created created appro- 
priate ASL rules that will allow this cmaO to pass through 
without requiring WBM vafidation. 

[0095] If the maximum instantiations has been reached as 
determined by step 1013, SkProxy docs not insuntiaie any 
further proxy entries and passes control to step 1010, return- 
ing to the Redirector. The net cf&ct of disallowing further 
instantiations will be that no ASL rules will be entered and 
since it is highly Kkcly that no ASL rules alrca^ exist with 
thiig sender’s email address, the sender’s email will most 
likely be rejected by tbc Redirector. 

[0096] FIG, UA illustralcs a sample repcesentalton of the 
SkProxy Thhlc (“SKTO ^ SkProxy-rclalcd infor- 
mation. This table's fuDdion is lo record all proxy 
afVt TCJSs r y available along with various characteristics that 
direct what kind of ASL entries the proxy address will create 
upon iustaaliation. The following describes each field: 



Lobcl lA FIG. UA Ojlumo Description 

t Prozyeddreu: Ibc email address Hut can te 

out try tho ciid*osoi; Scstdera scodiag email to this 
•ddms will rsa^ the sad-uaer if Uie preper 
oonditicna are mcL 

b Cfue the real cinaO address of the SpomKafiti 

end -user 

e cication dnto: the date this proxy addicts was 

created 

d ezpiiatiOQ type: Relarivo or Absolute. A relative 

cipirarioo will expire this proxy based oa the 
number of dates elapsed from the date of a specific 
pr oxy addicu instantiiUOD. Aa a ln o lu tp aqnnUioa 
wDI expire Ibis proxy bated on the ountber of dates 
elapsed fiom the date of initial proxy address 
ujvatioii. 

e explraltoo dayr Ihc amount of days to allow to 

liaoiTin. in conjunction with field d above 
to decide if a proxy addicu has expired. 

f mix srmdcis: the maidxntnn aBieoat of dinercni 

loadBfs that may Instastiaie ve tbif pmxy addreis. 

g pnoTf type: whether to create an ASL entry to allow 

the etitire docuia of the seeder, oi osl the specific 
email address of the acada 



[0097] The following explains the sample data presented 
in FIG. UA and dcsciibos their applicalion in tbc SkProxy 
technology: ^ 
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Row E»upp)c and de tcriptipo of jwc 

1 Tbe end<uor will give It ml lo a persoa at a meeting with tlie 
iotsnt of aDo'wing anyooo fioin lint company lo send email to tto 
subaenber. Wbsa the fint email coma fifom that pen on, the 
skProxy proens will intaadalt tUs coUy. and nulco an cutfy ia 
Uu ASLttble to allow foi any emaDi from this domiia lo poas 
thioogb M "CnemT. Tl» maj^un Maderi allowable » aet 

to 1 , 80 tlx ccader*! domiia will bi the Ant tod the only 
allowable domtin (company) to use thU proxy 

2 EncHucf has given Ihii pioi^ odditsi to subfoibe to a 
newsletter aod hu deRn^ Ibc proxy to allow 2 diferent 
scoden to UfO the proxy amail addbesk. 

3 Esd-incr is creatiog a private oiaO oetwoik to execute a small 
piojecL Because the expiraUon was abselutei Ihis proxy will 
expire 720 dsya alter Dee. 27, 2002. Up to 5 scoden may use 
the same pmn^ address. 

4 Tke end-user will be piovidisg hh/her email acUiess at a 
coqxjisu Web ailc. When the finl cm^ comes Cram that nia, 
tbe akPtO ]9 process will isstaatiate this entry, and make an 
emry in the ASl table lo allow for any emails Bom that 
specific only to pass through as a "friamT*. 

Bccsosc max senders is set to 1, the ftxit sender 10 

insun title the address wfll aka be the only sender the! con use 

that proxy address. 

5 &ad*tucr has given proxy address to snbacribc to d oewslcttar 
and haa rfefined the proxy to allow 2 different domains to nm the 
proxy emiil address. Tbe expirstioo Is set to 0 which means this 
proxy oddrea will never expire. 

d Bod user iTitcTtds to phrae on oidc^ docs not want (ho proxy 
to expire, and will allow op to 3 dt&erenl tenden to uao (he 
same proxy address 



[0098] FIG. UB Dluslrates a sample reptesontation of tbe 
SkProxy Insianliation Tbble (“SKIT') used lo hold specific 
proxy instaatiation tafoimalioiL This table’s Enaction is to 
record each itsUoliatioo of the proxy addres, especially tbe 
scoder’s email address. Tbe Eollowing describes each fide}; 



Labd in FtO. llB Colmnn Dsscriptton 

n Proxynddreis; same os FIC. IIA, cohixui a 

b kisuntiatifxi date: the date Ihis proxy eddiess was 

insuntiated for this sender 

e soodtx id: the inGorcniiian lo the loB of Iho ^ sign 

of the sender's [xbarnel email sd drci sc f 
d sender domsin: the isfisnnntion r^l of the tg)^’ 

sign of the sender's Internet emsil add r es s es 



[0099] The foUowiog explains tbe sample data presented 
in FIG« IB aod describes the detailsof various instantiatioDS 
correspondiog to tbe sample data provided ia FIG* HA: 



Qincsponding 
row id no. 

Row 13A Descr^t ba 

1 1 The serekr tom@ecxscxom seal on eimil to the 

proxy addiea jusUorsancO^mkspuxom. This 
row was iasmiitlated oo ■ result and cubsequcotly 
Ttxn*s email west threngh to (be tod'user wftbciul 
requiring the WBM vnlidotioa. B e es u ae tbe 
ci^umn Ms Uu ooncspoodlng row to FIG. IIA 
for this proxy address shows o Bmil of 1 sender 
ody Ibm can scad email to 
justroficmctSapemlapa. 



CbrrnspoodiDg 

fowtii no. 

Row nA Dcsc rqilioo 

com. Anyone else sending an email to 
justforacine@ipiixilaipuxain will recsivc an 
industry^daad^ "no such user" enw 
message. 

The proxy address *£oa 3 ci sli i « «s®sp»Tobpu. 
com'* was gives out by the end>uscr to wbftcribo 
to a ncwwlcttcr. TIU ncwnlcUor service sends cut 
a coofinsing email before surfing the lubscr^ 
tnm. This row's instasUsiloa is the rssuU of 
receivmg s coafinning emaD from the oewtleUer 
service with a “FROVr adtben of “ooaRnn® 
fobscribciBxxnn'', wfaidt passed thiongh to the 
end^Bor witheut requiring WBM i^Hdalion. 

ITiJs row's instantiation is the result of receiving 
the actuil newsletter. A second email hum the 
oewilettei scfvioo wkh a “FROVT ^dress of 
■*oewslattai<<Ssubiqibcw .cain*, whiidi passed 
through to tha eadHiicr wlthoot requiring WDM 
validstioa. Suhaequent newstcuers hive tbe same 
“F RO M* oddreaa and therefore do not oentc 
addldoaal instantiation records and also pan 
through wilhoot Wl^ valtdadon. Because the 
mqy gcedeis field in column f of the corcc^ 
speeding row in RG. 11 A » setto 2 and 
because there are 2 entries ia Uiis table, 
any other emu! ncnl to Iho proxy addrea 
**AjDandaltunta®qrom]upa will 
sot be tniuatinted in tbe 5XTT table, no ASL 
rules will be created, sad as a mult Ure 
S^samXapu server will renifn sn indnsuy siaiMhiid 
**00 aicb user* caoi mesiaga. 

Rows 4, 5, and 6 illastrate 3 differeat aenders that 
ate using the tsme proxy address. Emails from 
these senders will pass through without o WBM 
piuceis. Because the coneiponding entry m lh« 
SBa* tabls shown m FtG UA, row 3 column f, 
that there are 5 max scodera sllowed, 
and there are only 3 different scodea ia this 
table, 2 moro diBcreex senders may send an emad 
to 98r74331@q»mkapuxonj wtthoui requiring 
WBM validation. Afler. the ^ ndditlonal inunotia- 
doQ* hove occurred, however, sny other staders 
Ti«hq» the 96743Sl@6pamhapoxom ennafl addrc» 
will receive an tadust^stanriaid *no such uwr 
error message because no addldoisO chuicn ia 
Ihc ASL table will be made. 

Sec description for PIO. 11B Row 4 aboya. 

See description for PIO. IIB Row 4 above. 

The Web siie that received a communicatbo from 
die ond-uscr has replied by sending na cm^ 
FROM salcs@yocjshocsAMn TO: 456789© 
spamkapojoenn. This row is the resulUng 
lostanttnlioa. Bccansc cohimn f in die 
corresponding row in FIO, JlA shows a max 
sender of 3, any other tender (hot nitempu lo 
send an emaO to 45^89@ipnvdapuxxnn will 
reccivu an udustry^iaodasd “no such mof'* 
error moBSogc. 

Note that there is aa entry in FK3. 11A but there 
ia no corresponding entry in PIO. 11 B. This is 
beensa oo sender has sent an email lo the proxy 
addreas in column a of the oorreapomUag row ts 
FTO. 31A. 

t<fote that there is aa entry in FtG. IIA but there 
b no correi^oedlng eidiy In FIG. 11 B. This ia 
because no seedei has scat an email to the proxy 
sddrets in odums a of (he conaqronding row In 
FTO. IIA. 




[0100] FIG. 12 provides a detailed deacripdoti of the 
inaUiUiaticHi process. **SKPP’ is defiood to mean ‘‘SkPioxy 
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Preprocessor". la Step 1201 the SKPP searches for aad 
matches the proxy email address (in the field) in the 
SKT ^xjrwn in F1G« UA. St^ 1202 extracts the sender's 
email address in to two parts, the "userid" rcpresooled by 
ibc ioformatioa to the left ol toe symbol in an Imeroet 
standard email address, and the doinaio, repiesented by ibe 
information to the ri|;bt of toe symbol in an Internet 
susdaid CTail address. Step 1204 detmoines if the proxy is 
for an entire domain or for only a specific user email address. 
Step 1205 adds an entry in toe ASL tabic to allow this and 
any fuTtber emails from this entire domain to be fdeotifled as 
FRIEND" without further vaHdatioo. An entire domain 
proxy would be usefiol if a user wanted toe proxy email to 
be used by anyone within that domain; examples might 
include onHoe orders or newskitcre where it is aoocpubic to 
receive email from any address within that domain such as 
ordcr-coDfinnation®amazoa, order-status@ani azon.com, 
order-sDppori@amazoo.com. Step 1203 adds an entry in the 
ASL table to allow Ibis and any further emails from this 
specific email address ooly to be identified as “FRIEND" 
without further validation. A specific user address proxy 
may be useful if one wishes gives out an email address lo a 
specific individual without forcing that individual to go 
ttoougb a validation process. In Step 1206, an entry is made 
in toe SKIT table shown in FIG. UB and all Che fields are 
filled. Step 1207 returns control to Step 1012 in FIG. lOC 
and the proxy processing process contiiiues. 

[0101] Once a has been instantiated, 

it can ooly be used for toe ^cific FROM domaio or email 
address that it was instantiated tor. For example, if an 
end-user submitted their domain-wide proxy email address 
for toe purpose of an onb'nc order, and that email address 
was subsequently instantiated, tbe proxy email address 
cannot be successfully used by a sender that does not use the 
same domain name as toe ooHoe order vender. 



[0102] By dcfiniogjtb^maxi^ amount of senders that 
may use a given pri^ a^i^ toe eod-user can effectively 
create "private eoiail’DBl^rks" whereby the proxy email 
address will worh for collection of individuals or organiza- 
tious but docs not work for others. 



[0103] Existing standard email configurations as shown in 
FIG. 13A use an email server 1302 to reedve eroail, store 
email in an inbox lo be retrieved by client computer, and to 
transmit email sent by toe client computer 1301. The 
-unprovemem in this invendou as shown in FIG. 13B allows 
a SpamKapu server lo be easily installed in aa existiag email 
network as a hardware network appliance device with mini- 
mal reconfiguration of toe existing network and/or addi- 
tional maintenance labor from staff. 

pi04] FIG. 13B illustrates bow too inventioa would be 
installed so that any incomijig email would first pass through 
the processing of tbe SpamKapu server. Only validated 
FRIEND email would pass through to toe ^levioii^y) 
existing email server 1302. All existing configuration and 
processing on that existing email server would conUnue 
unchanged. Outgoing email would go from the efiem com- 
puter 1301 to tbe existing email server 1302 which in-tpru 
will use iodustry-standard relay specifications to pass its 
email to the SpamKapu server 1303 which would copy all 
redpient email addresses to its ASL Rules List as 
** FRIENDS" then send the email to its intended destination 
server and redpient. This conliguratioD provides a simple 
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and transparent method to both block all incoming spam and 
easily copy the outgoing cmailiog addresses into the ASL 
Rules Usi, 

[0105] FIG. 13C illustrates bow the invention can be| 
installed at an ISF facility lo provide ^am protection lo tbe 
subscriber base. Tbe SpamKapu email firewall 1303 is 
installed to process mail addre^d to subscriber accounts 
1306. Subscribers interact with tbe SpamKapu email fire- 
wall 1303 via the provided Web interfaces and XML inter- 
faces (see FIG.fi). In this coufiguralioo, spam protection can 
be provided to an ISF subscriber base. 

[0106] Fi6. I3D illustrates bow tbe iovendon can be 
installed at a network conocctivity provider's facility to 
effectively ofifioad spam-related email bandwidth for ISI^ or 
corporate installations. All incoming email from tbe Internet 
1305 is scut to toe network provider fiadfity 1304 that 
typically has significanl bandwidth capability. All ^am« 
i^led email is rejected by toe SpamKapu email firewall 
1303 as described previously. The remaining spam-free 
email 1307 then passed lo toe lSP or corporate emaO server 
1302. Tbe end results is the effiective reduction of bandwidth 
used to simply transmit 

[0107] FIG. 13£ illustrates bow the invcniion can be 
ioslalkd at a wireless telephone service provider fiidlity to 
provide ^am protection for wireless subscribers. Most 
carriers provide an Infcrnct email gateway 1308 whereby 
wireless subscribers can scud and receive Internet email. 
The SpamKapu eroail firewall 1303 is installed to process 
mail addressed to subscriber accounts 1307. Subscribers 
interact with toe SpamKapu email firewall 1303 via toe 
provided Web interfaces XML interfaces (see FIG. 8). 
To provide added frinctionality for wireless phone subsenV 
CIS, an additional commuuica^n layer that follows toe ViAP 
(wireless access protocol) ts iUusiralcd to allow subscribers 
to mteract with the SpamKapu firewaB using only their 
wireless device. In this configuration, spam protection can 
be provided an wireless subs^ber base. 

[0108] The firewall configuratioo is not inletxkd to 
replace any cxisimg firewall devices operatiog on the net- 
work. For network coniiguratioD purposes, toe SpamKapu 
email firewail replaces the existing email server that pro- 
cesses external incoming email and transmits email 
addressed to external servers. The ideal configuration of toe 
SpamKapu firewall is to be considered a hardware compo- 
nent alongside the existing email servers and in copjuoction 
with any other existing firewall devices. 

[0109] The optimal commercialization of the SpamKapu 
server will be as a oetwoik appliance. This can be packaged 
as a complete hardware and sofrware solution or the soft- 
ware can be installed on dedicated hardware by. knowledge- 
able technicians. The key eovisioaed commercial applica- 
doD8 include A} Commercial ISI^ that use the SpamKapu 
tcchoology to provide spam clnuinaijoen services to their 
clients. B) Network providers that ofifor both ^am elimina- 
lion and reduced bnodwidlb usage. 

[0110] FIG. 13F illustrates how SpamKapu can be 
installed on an existing email server 1311 in a pure software 
configuration. The established Internet email standard pro- 
tocol uses TCP/IP port 25 lo send and receive email. By 
icconfiguring toe existing email server 1311 to look for 
incoming email on another port, for example 1125, and 
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traosmii email oa port 25 and configuring SpamKapu soft* 
ware 1312 to look for moomiag mail on port 25 and scad its 
mail through port 1125, the SpamKapu server is properly 
inserted into the email transmit and receive proccs. In the 
case of incoming email, It is first routed through Spam* 
Kapu's receive process in step 1312 via port 25 and than is 
sent to the existing email server via poit 1125 where the user 
client 1301 can retrieve the email. In the case of outgoing 
mail, the client connects to SpiniiCapu*s transmit process 
via port 25 whidi performs processing as detailed in FIG. 
36, and is then scat via port 1125 to the existing email server 
1311 which m*tum sends the email to its dcstinatioa over the 
ioicmet via port 25. The configuratbn lEustratcd xu FIG. 
13F allows the SpamKapu invention to be installed on 
existing server hardware thereby lowering the overall cost 
V^^acd maiolcnance involved with additional hardware. 






[0111] In summary, the present invention provides a spam 
email rcjeaioo method which analyzes the sender address of 
incoming email and deicrmloes whether it is to be rejected 
before being accepted by an eroail-ieoeivtng server by 
retumiog a standard **no sudi user'' ciror ocxie or rcdirectiog 
it elsewhere. This provides an advantage over existing 
anti*spam filtering systems which accept afi email and 
attempts to filter out only those that have sender addresses 
recognized as those of known jammers. The invention 
employs an ASL module to capture authorized sender email 
addresses from the user’s outgoing email or other sources in 
Older to update the **authorized senders'* (ASL) Ixsis. The 
WBM procedure allows senders of rejected email to go to a 
separate website and register os valid scoders after passing 
an ioteracliOQ test that pnn firms that Ji is not b eing done bv ^ 
^ mechanical progrant.l rbe SkProxy prooedtirc allows sab- | 
senoers to temp^ary proxy addresses for receiving j 
email expeaed from unknown sources and instantiates send- J 
CIS as authorize d upon receiving th e expected e mail to the / 
[proxy addresses^ ioe uoaui!ionz^U>eiJUi] lejeuiUfl compo* 
nteni fii lhc"syjiM cao be readily configured as a hardware 
or software appliance used in tandem with a oouvcDtional 
cmaQ server, email gateway, or firewall to an intranet, or as 
a software extension to an existing firewall system. 



[0112] It is understood that many other modifications and 
variations may be devised given the above description of the 
guiding principles of the invention. It is intended that all 
such modifications and variations be considered as within 
the spirit and scope of this inventioD, as defined in the 
following claims. 



1 claim: 

1. A system for eliminating unauthorized email scot to a 
user on a network comprising: 

(a) an email client for allowing the user to receive email 
^nt on the network addressed to a unique email 
address of the user, 

(b) an enail-rcceiving server connected between the 
network and the email clicni for receiving email 
addressed to (he unique email address of the user, 

(c) an uaa.uthorizcd*email rejcctioo compoocnl having an 
authorized senders list (ASL) module which mauilaius 
email addresses of senders authorized to send email to 
the user, wherein the nnaulhorizcd-emai] rejection 
component is opereblo with the email*recciving server 



for intcicepting and rejecting any unauthorized email 
addressed to the email address of the user. 

2. A system for cHminaliDg unauthorized email sent to a 
user on a nctworic according to dalm 1, wherein the unau* 
thoDzed-email rejection compooent is positioned in the flow 
of incoming email upstream from the emafi-iecerving server 
such that unauthorized emaO is intercepted and prevented 
&om reaching the cmail-fcceLviog server. 

3. A system for climlniting unauthorized email sent to a 
user on a network according to claim 1, wherein the unau- 
thorized-cmail r^ection component is configured as a hard- 
ware appliance that is positioned in the flow of incoming 
email physically upslream from the email-receiving server. 

4. A s^cm for eliminating unauthorized email sent to a 
user on a network according to daim 1, wherein the unau- 
thorized-email rejection component is configured as a soQ* 
ware component operable in the flow of uicoming email 
logically upstream of the email-rcociving server, 

5. A system for eliminating unauthorized email scot to a 
user on a network according to claim 1, further comprising 
an email proxy pre-processing module that allows users to 
designate a des^atioo proxy email address for use by a 
sender in instances where the email address of an authorized 
sender is not yet known, examines incoming email and, 
upon recognizing the destination proxy email address of the 
user, accepts the email and sends it to the user. 

6. A system for climinatiog unauthorized email sent to a 
U.SCI on a network aocoirdmg to claim 1, further 'comprising 
a WBM component for sending a message to a rejected 
sender inviting lire sender to be validated as an authorized 
sender. 

7. A system fm eliminattog unauthorized email sent to a 
u»r on a network according to claim 6, wherein the WBM 
componcat ^petrifies a predetennined time period for the 
sender of rejected email to be validated as an authorized 
sender. 

8. A system for eliminating unauthorized email sent to a 
user on a network according Co claim 6, wherein the WBM 
compooent is installed on a separate website that can be 
accessed by a sender of rejected email to be validated as an 
authorized sendee . 

9. A system for eliminating unauthorized email sent lo a 
user on a network according to claim 6, wherein the WBM 
compooent requires a sender of rejected email to pass an 
intenction procedure to show that the scDdei is not a 
mechanical program attempting to aulomatically validate 
the sender. 

10. A system according to claim 9, wbereiu the interaction 
procedure includes a display of a gropbic image of a word 
C 3 T object, and an input for the sender to color in a text word 
in respoose to foe graphic image, whereby the system can 
confirm that the interaction procedure is not Ireing per- 
formed by a mechanical pregam. 

11. A system according lo claim 6, wherein once the 
sender is confinned as an aulbcrized sender of email to the 
intended recipient ixsei; the WBM (remponent sends an 
appropriate update to the ASL module that allows subse- 
quent emails from the sender to pass through nonnaUy. 

12. A system according to claim 1, wherein the ASL 
module LDchxdos an ASL database for storing ASL lists of 
processing rules and authorized sender addresses for respec- 
tive usees of the system, and a spam processor module for 
processing the ASL rules lists lo determine If the sender is 
friend, spammer, or unknown. 
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13. Asystem acoording to daim 1, wbcieiji, upon the ASL 
module dctcxiniaing that incomiiig email has a seixier 
address that a not that of an authorized sender, said uoau- 
thorized-eoiail rejectioo component rgccts the incomixig 
email with an indusiry standard “no such user^ eadr cncs* 

Mgp. 

14. A system aceoidiag to claim 1, wherein the ASL 
module includes an ASL list manager for analyzing email 
header information including FROM and TO addresses of 
email sent by users to dynamically update the ASL lists of 
aotborized sendees. 

15. A system acconting to claim 1, wherein the ASL 
module includes a rules proce^r for processing authorized 
sender addresses for updating the A$L lists using data foom 
an email address source selected £mm the group of email 
address sources consisting ot received emaS; sent email; 
user inputs lo emaQ service fonedons on the emaQ client; 
inputs from user browsing of web sites; user desktop orga- 
nizer and other contact lists; and third party address emaO 
management programs. 

16. A system according to claim 1, wherein the ASL 
module inchidea a rules processor for processing analysis 
rules for updating the ASL lists using data from an analysis 
source selected from the group of analysis sources consist- 
ing of: user email log analysis; expiration date analysis; 
low/high email volume analysis; fii^ logic analysis; and 
third party data analysis. 

17. A system according to daun 1, wherein the ASL 
module maintains the ASL lists u^g a designation of 

, $eDde^address sUtus selected from the group of sender- 

address status designations consisting of: always authorized 
as a friend; authorized as a Mend over a date range; 
authorized as a friend before an expiration date; authorizing 
an email for a given domain name; autboriziag all email for 
a domain or any subdomain; always rejected as a jammer; 
rejected as a spammer matching a black list; static rolurned 
by executing a 3”* party email software; and rejected as a 
spammer sent with an error message. 

18. A method for eliminating unauthorized email sent lo 
a user on a network comprising the steps of: 

(a) receiving incoming email addressed to the unique 
email address of the user, 

(b) maintaining an authorized sendera list (ASL list) of 
email addresses of external users authorized to send 
email to the user, 

(c) processing the sender's croai] address on incoming 
email by comparing it to the ASL Ust, and 

(d) rejecting the receipt of incoaung email before the 
email can be accepted for delivery to the user if the 
results of processing the ASL list lecurns with a result 
of “unautKorized sender^ by returning an industry 
standard ”oo such user^ error code. 

19. A method for eliminating unauthorized email sent to 

i a user on a network comprisijig the steps o£ 

(a) receiving incoming email addressed lo the unique 
email address of the user, 

. (b) mainlainiog ao authorized senders list (ASL list) of 
email addicsses.oC external users authorized to send 
email to the user, 

(c) processing the sender's *email address on icooming 
email by comparing U to the ASL list, and 



(d) rejecting the receipt of incoming email before the 
email can be accepted for delivery to the user if the 
results of processiog the ASL list returns with a result 
of 'hmaut^rized sender", sending a message inviting 
the sender of the rejected email to conflrin that the 
sender is an authorized sender of email to the intended 
ttdpienl by passixtg an interacUoo procedure to show 
that the sender is not a mechanical program attempting 
to automatically validate the sender, and thereupon 
adding the validated sender's email address to the ASL 
list. 

20. A method for eliminating unauthorized email sent to 
a user on a network oomprisiog the sc^ of: 

(a) receiving inooming email addressed to the unique 
email address of the user, 

(b) m amtainin g an authorized senders list (ASL list) of 
email addresses of external users authorized to. send 
email to the user, 

(c) processing (be seeder’s email address on incoming 
email by comparing it to the ASL List, 

(d) rejecting the receipt of incoming email before the 
email can be accept^ for delivery to the user if the 
results of processing the ASL list zeturas with a result 
of 'Hioauthorized sender", and 

(e) allowing a user to designate a destination proxy email 
address for use by a sender in instances where the email 
addres of an autbtxizcd sender is not yet known, 
wbcTcin if the destination proxy email address is rec- 
ognized on incoming em^, the incoming email is • 
accepted and sent to the user. 

21. A method for eliminaling unauthorized emaQ sent to 
a user on a nctwoik comprising the steps of: 

(a) receiving inooming email addressed lo the unique 
email address of the user, 

(b) maintaining an aulborized senders list (ASL list) of 
entail addresses of external users authorized to send 
email lo the user, 

(c) processing the sender’s email address on incomii^ 
email by comparing it to the ASL list, and 

(d) rcjcctiog the receipt of irKX)ming ecnail before the 
email can be accept^ for delivery to the user if the 
results of processing the ASL list returns with a result 
of '^unauthorized sender", 

wherein the ASL module includes ap ASL list manager for 
analyzing email header infonnation Including FROM 
and TO addresses of email sent by users to dynamically 
update the ASL list of authorized senders. 

22. A method for cUmisating unauthorized email sent to 
a user on a network comprising the steps of: 

(a) receiving inmmiT^ email addressed to the unique 
email adtiress of the user, 

(b) maimaining an auiborusd senders list (ASL list) of 
email addresses orextcrnal users authorized to send 
email to the user, 

(c) procc^ing ibo sender’s cmaO address on incoming 
email by comparing it to the ASL lis^ and 
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(d) rejecting ibo recent of inoomii^ email if the results of 
pcoocssxDg tbe soader*s email address with the ASL list 
returns with a rcsull of **iu3aalbori2ed sender”, wherein 
the icjccUon of (be incoming email is performed in a 
ph>si^ or logical operation bcibre the email can be 
oocepted for delivery to the user. 

23. An unauthorized-email rejection compooent for use 
with an emaiUnecexving server for receiving email seal to a 
user 00 a network comprising an authorized sendcre list » 
(ASL) module which maintains an ASL list of email 
addresses of scod^ authorized to send email to the user, 
wherein said unauthorized-email rcjcctibo oomponent inter- 
cepts and rejects any incomit^g eraail addressed to the email 
access of tlie user if the processing results of the ASL list 
returns with an **uaauthorized sender'* result, wherein the 
unauthorized-email rejection component is a hardware or 
software aj^liance positioned for operation in the Sow of 
incoming email physically or logically upstream from the 
cmtil-reoelviog server to prevent any unauthorized emafl 
from reaching the email-reoeiviiig server. 

24. An unauiboiized-email rcjeclioa component for use 
with an email-receiviag server for receiving email sent to a 
user on a network 'comprising an auibonzed sc adore list 
(ASL) module which maintains an ASL list of email' 
addresses of senders authorized to send email to tbe user, 
wherein said uaautboiizcd-eman rqecdon compon^ intcr- 
cq>ts and rejects any incoonug email addressed to the email 
address of the user if tbe processing results of the ASL list 
leiums with an ** unauthorized sender** result, wherein the 
ASL module includes an ASL list manager for analyzing 
email header infonnatioa including FROM and TO 
addresses of email sent by users to dynamically update the 
ASL lists of authorized senders. 

25. An unauthorized-email rgcction compooent for use 
with an cmail-receivtng server for receiving email sent to a 
user on a network comprisiDg an authorized sendees list 
(ASL) module which m^tains an ASL list of entail 
addresses of senders authorized to send email to the user, 
wherein said unautbonzed<emaiI rejection component inter- 
cepts and rejects any incoming email addressed to the email 
arforess of the user if the processing results of the ASL list 
returns with to ^unauthorized sender" result, and frmber 
Including a proxy address module for allowing a user to 
designate a destination proxy email address for use by a 
sender io instances where the email address of an authorized 
sender is ix)l yet knowo, and if the destination proxy email 
address is used on mcoming email, for aoci^ting tbe incom- 
ing email and sending it to the user. 

26. An unauthorized •email rejection component for elimi- 
nating unauthorized email according to claiin 25, wherein 
upon receipt of incoming email using the destination proxy 
address, an entry for the email address of the sender thereof 
is dynamically created in the ASL module as an authorized 
sender. 

27. An unauihoilzcd-einall rejection oomponem for elimi- 
nating unauthorized email acoordiQg to daim 25, wherein 
said uoauthorizcd-cmail rejection processes the iocotniog 
email using the desdnaiioa proxy address acooiding to rules 
that permit email to be acceded from a specific user, 
do main , and/or subdomain represented in the proxy address. 

28. An unauthorized-email rejection componem for use 
with an email-recelvtng server for recetviog email soul to a 
user on a network ooroprisiug ao authorized seodera list 
(ASL) module which maintains an ASL list of email 



addrcKcs of senders authorized to scud email to tbe user, 
wherein said unauthorized-email rejection component inter- 
cepts and rejects any incoming email addressed to the email 
address of the user if the processing results of the ASL list 
returns with an 'hinauthorized sender" result, and further 
including a redirector module for sending a message inv iting 
the sender of the rejected email to ooofrrm ibat tbe sender is 
an authorized sender of email to the intended recipient by 
passing an mlcracHon procedure to show that the sender is 
not a mccbaoical program altempiing io automatically vali- 
date the sender, whereupon the validated sender’s email 
address can be added to the ASL list. 

29. Ad uoautfaorized-eiiiBil rejection compozieat for use 
with an email-receiving server for receiving email sent to a 

oa a network oomprisiag an authorized senders list 
(AS^) module which mainloins ao ASL list of email 
addresses of senders authorized to send email to the user, 
wherein said unauthorizod-email rejection component inter* 
cepls and rejects any inooming email addressed to the email 
address pf the user if the processing results of the ASL list 
returns with an 'hmaatborizcd sender'* result and relums an 
ifxlustry standard "no such user" error code before the email 
can be accepted for delivery to the user. 

30. A system for eliminating unauthorized email sent to a 
User oD a network comprisiag: 

(a) an email client for allowing tbe user to receive email 
sent on tbe network addressed to a unique email 
address of the user, 

(b) ao cmail-rccciviDg server cooncctcd beiweeu tbe 
DCtwmk and the email cliem for receiving email 
addressed to the unique email address of the user, 

(c) an unauthorized-email rejection component having an 
authorized senders list (ASL) module wtuch maintains 
email addresses of scndeis authorized to send email to 
the user, wherein the uoauthoiucd-cmail rcjecdoD 
compooent is operable with the email-receiving server 
for intercepting and rejecting auy unauthorized email 
addressed to the email address of the user, 

wfaeiein the unauthorized-email rejection component is 
positioned for operatioa in the flow of iocoming email 
physically or logically upstream before tbe email- 
receiving server such that unauthorized email is inter- 
cepted and prevented from reaching the email-receiv- 
ing server. 

31. A^stem for eliminating unauthorized email sent to a 
user on a network comprising: 

(a) an email diem for allowing tbe user to receive email 
scat on the uelwodc addressed to a unique email 
address of the usoi; 

(b) an emaJl-reoeiving server oonoecied between the 
network and the email client for receiving email 
addressed to the unique email address of the user, 

(o) an unaulhorizcd-CTnatl rejection component having an 
authorized senders list (ASL) module which maintains 
’ '‘email addresses of seoders authorized to send email id 
iKh' user, wherein the unauthorized-email rejection 
oomponent is operable with the email-receiviag server 
for intercepting and rejecting any unauthorized email 
addressed to the email address of the user, 

wherein the uoBulhorized-cmail rqjectfon oomponent is 
positioned for operation in (be flow of incoming email 
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physk^ly or logiuiUy upstream before ibe email- 
receiving server such that unauthorized email is imer- 
ccpicd and prevemed fiom reaching the email-receiv- 
ing server, and 

wherein, upon the ASL module detcrminiiig that memmiog 
email has a sender address that is not that of an 
authorized sender, said unauthorized-cmaii rejection 
component rejects the incoming email with an industry 
standard "no such user'* error message. 

32. A system for eliminating unauthorized email sent to a 
User on a network comprising; 

(a) an email client for allowing the user to receive email 
sent on the network addressed to a unique email 
address of the user, 

(b) an email-rcoeiving server oonnected between the 
network and the email dicnl for receiving email 
addressed lo the unique eroail address of the user, 

. (c) an noauthortzcd-email rejection component having an 
authorized senders list (ASL) modulo which maintains 
email addresses of sen^rs authorized to send email lo 
the* user, wherein the unauthorizcd-enaail rejection 
compooent is operable with the cmaO-recciving servaj 
for intercepting and rgectiag any unauthorized omail 
addressed to the email address of the user, 

\ wherein the unauthorizod-email icjcciion component is 
positioned for opeialioo in the flow of inconziog email 
plijwally or logically upstream^ before the email- 
r^^iving.. server such that uotmthbrlzed email is inter- 
cepted and picvcoted from reaching the email-receiv- 
ing server, and ■ 

wherein the ASL module iizcludcs an ASL list manager for 
analyzing email header uiforman'oo including FROM 
and TO addresses of email sent by users lo dyoamicaliy 
update the ASL Ust of authorized soodeis. 

33. A i^tein for eHminating unauthorized email sent to a 
user on a network comprising: 

(a) on email clt^i for allowing the user lo receive email 
sent on the network addressed to a unique email 
address of the user, 

(b) an email-receiving server connected between ihc 
network and the email client for receiving email 
addressed to the unique email address of the user, 

(c) an unmthorizcd-cmai] rejection component having an 
amhorized senders list (ASL) module which maintains 
email addresses of seodeis authorized to send email to 
the user, wherein the unauthorized-email rejection 
con^nem is operable with the emaO-reccivu^ server 
for inlerocpling and rejecting any unauthorized caiail 
addressed to tbe email address of the user,. 

wherein the un authorized •email rejection component is 
positioned for operation in the flow of incoming email 
pbyM^^ly or logicaUy upstream before the email- 
rtcciving server such that unauthorized omail is intcr- 
cq)tcd and prevented from reaching the email-receiv- 
ing server, and 

wherein said uoaulhori 2 ed*email rejection oomponent 
includes a redirector oiodule for sending a message 
inviting the sender of the rejected email to confirm that 



the sender is an authorized sender of email to the 
intended recipient by passing an iotersetioa procedure 
to show that the sender is not a mechanical program 
attempting to automatically validate the sender. 

34. A system for chminating unauthorized email sent to a 
user on a xxtwork oomprising; 

(a) an email client for allowing the user to receive email 
sent on the network addressed to a unique email 
address of the user, 

(b) an email-receiviug server connected between the 
network and the email clknl for rcoeiviDg email 
addressed to tbe unique email address of the user, 

(c) an unauthorized-emafl rejection component having an 
Bulhorized senders list (ASL) module which maintaios 
email addresses of senders autbori^ lo send email to 
the user, wherein the unauthorized-email rejection 
CDiupoiiem k operable with tbe email-receiving server 
for intcrccpliDg and rejecting any unauthorized email 
addressed to the email address of the user, 

wheieio said system includes a proxy address module for 
' allowing a user to designate a destination proxy email 
address for use by a sender in insianoes where the email 
address of an authorized sender is not yet known, and 
if tbe destination proxy email addr^ is used on 
incoming email, said unautborizcd-cmail icjcciion 
component accepts the incoming email and sends it to 
the user. 

35. A system for elimioaling tuiauihodzed email sent to a 
user oa n network comprising: 

(a) ID email dient for allowing the user to receive email 
sent on the network addressed to a unique email 
address of the user, 

(b) an email-receiving server oonnected between tbe 
network and the email dient for reocivipg email 
addressed to the unique email address of the user, 

(c) an unantbc^izcd- email rcjcctioD compoocnl haviog an 
authorized senders list (ASL) module which Huuntaios 
email addresses of senders authorized to send email to 
liie user, wherem tfao unauthorized'email rejection 
component is operable with the email-receiving server 
for intercepting and rejectiDg any unauthorized email 
addressed to the email address of tbe user, 

wherein said unauthorized-email rejection component 
includes a redirector module for sending a message 
mviling the sender of the rejected email lo confirm that 
the sender is an authorized sender of email to the 
intended redpiont by passing an imcraclion procedure 
to show that the sender is not a mechanical program 
at tempting to automatically validate the sender, 

wherein the interaction procedure includes a di^lay of a 
graphic image of a word or object, and a requesl to the 
andcr to enter a text word in response to the graphic 
image, whereby the system can conOnn that the inter- 
action procedure is not being performed by a mechani- 
cal program, and thereupon add the validated sender's 
email address to tbe ASL list. 
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Specification for SpamKapu 
Copyright CyberCom, Inc., 1999, all rights reserved. 
Reproduction or copying of this material or its use In the 
creation of derivative works without the express permission 
of CyberCom, is a violation of federal law and may result in 

civil or criminal penalties. 

(a) Application transmittal form. 

(b) Fee transmittal form. 

(c) Title of the Invention. 

’SpamKapu" Software to ^knJnate unauthorizwi receipt of 
^ectronlc m^l (spam) 

(d) Cross Reference to related applications (if any). 

Internet SMTP, POPS, and rMatad standards 

(e) Statement of federally sponsored researchfdevelopment (if 
any). 

none 

(f) Reference to a microfiche appendix (if any). 

none 

(g) Background of the Invention. 

Not sure here. 

(h) Brief Summary of the Invention. 

Most if not all, of the cunent software to control spam Is based 
on Identifying lists of spam sources orsendsfs and filtering enmll 
based on those lists. This technology Is only as good as the 
Identlfjdng list and cannot guarantee that the user wBI not receive 
spam. Today’s spam corrtrbl software assumes allmiallis 
mthortxed an attempts (o filter out unauthorbed email. 

Because today’s spam tiltming technologies are based on lists of 
known spam sources. It Is Impos^de for them to flltw email that 
comes lirom nonSPAMMBts that la still undestred by the user. 

For Instance, one may have tUselosedtiiMr email address at a 
Web site which now used by Indhdduals that are sending email to 
the user. These IndMduals wUI never afuioar of spam lists 
because technically they are not spanmlim. 

SpamKapu based on tiie Idea that all emattls unauthorised and 
rmist be compared against an "authmrized senders" Hat hi order to 
boacc^tabletotheuser. This flttara not only spamming 
sources, but §0^ sender which the user deems as unauthorbed. 
This creates an Inherentiy powerful and 100% prtvateemall 
solution. 

SpamKapu Intelllgentfy formulates Oie "authorbed senders" Hst 
based on ansJysIs ofOie user’s email usage (such as sent email) 
and a gatherlrrg of key data such as tiiMr known contacts end 
associates. The autimrized senders list may also be mslly 
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manipulated by the user at any time to add orremave audiorizad 
senders. 



To summmbe: SpamKapu sitoctNety blocks 100% of 
unauthorized email to die user. It Is based on the Idm that If you 
did not send someone an emallf they are not audtwized to send 
you email. 

(i) Brief description of the several views of the drawing (if 
any). 

(I) Detailed Description of the Invention. 

SpamKapu Is formed of several key modulea and definitions: 
SUBSCRIBER: the person that using SpamKapu. 

FRIEND: an emalFsendlng source that is authorized to send 
email to the SUBSCRIBER. 

SPAMMER: an emaileending source using manual or highly 
mechanized means to send one or more emails throi^ the 
Internet that b not authorized to send emai to the 
SUBSCRIBER. 

CONTACT: an email-sending source that b a human being 
attempting to reach tto SUBSCRIBER fora legitimate cause. 
SUSPECT: an email sending source that has riot yet been 
Identified as either a SPAMMER or CONTACT. 

ASL Manager 

Software designed to populate the ASL from a varl^ 
of mettiods: 

Contact lists of the user indicating Friends. 

Continual analysis of sent mail logs which may 
expose additional Friends. 

Standard file formats (i.e. eomma-deHmited) which 
would allow subscribers to easily update their ASLs. 
Spam Processor (SP) 

Decides whether an email address Is FRIEND, or 
SPAMMER by executing rules on the SPDB In 
conjunction with the ASL. 

Returns thb result along with any message to 
include in the error response to the REDIRECTOR. 
Uses Industry standard PEm. programming synfaoc 
and incorporates as PERL Interpreter to execute 
rules. 

Spam Processing databsee (SPDB) of which a unique copy 
exbb for each SUBSCRIBER, composed of several tables: 
Authorized sender Ibt (ASL), containing 

An emaO address or nmtching pattern for an eaaan address 
Defiuilt: exact match 



A spedfk email addren 
jolin@coixq)ai)^.C(mi 
UNIX Standard wOdcard matcUag 
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* jnicR)6oltcoin Le. auyfluug fixxu. 
“MicroGK^Asa” 

•nxrosofi*: anyMig ^ mkanoeoft m 
it 

*jnQ; ai^ enal fiom fismOitaiy 
Matebingany known "bladdiolelist" by using a 
•^BLACKHOLE% qmbol. 

A condhiOTMl and psianicteis to cxecule if Ifae match b Inie 
An action and parameters to poform if fte comStKBial is 
true. 

A parameter used llie secondary action 

The last date the SUBSCRIBER sent email to this address 
The last date this address sent email to the SUBSCRIBER 
Date the record was created 

Example list of eondltlonalB to be used by the SPAM 
PROCESSOR, e.g: 

expiration dates. 

A givcii address until 2/12/2004 
Date ranges 

A given address from 4/1/2004 to 5/2/2004 
Specific learning times 

first week of every month but no other time, 
e.^ newdetterfaimagaTme jwn 
accqrtabledndng 1* wedcof each 

Trrmfli, 

A link to external si^ware dedgned to allow fiv additional 
usCT<de£ned oiteria 

This aDows tor 3*^ party ^ppUcattoas. 

Example list of different second^ actions to take 
Send a given message in the error reqxmse. 

Send a given message as an email. 

Open a file and email its conteots 

Open a file and send its contents as an error repemsB. 

Set toe sender’s status to SPAMMER or FRIGID 
Give SMTP de&oltetrw message 
Link and eacecute external software dedgnol to alow tor 
addidoDBl userdefined actions 

TUa allows for 3** party appiicatioiis. 

Listof messages that may be invok^ byaglven 

secondary action 

Standard "entn” 

Custom wito variable substhulion in toe message bocty, e.g: 
%aseiiuuDe% is substituted with toe sender’s 
emaO address 

%sttbid% is toe ID code of the subscriber 
%date% Is today’s date 

‘liello ^usemamcK yon luve been identified as apam, go to 
hMp://www.spamkapu.com/subscTibei«'4toibkWi and if 
yoa’te really human wcH let you m. 
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Custom text “All email addresses from America Online are 
unoonditioaalfy r^ected” 

Authorized Sender maObox (ASM) 

An electronic mailbox c<^rmlng to popular Internet 
standarda (as of thie writing, POPS & IMAP4) that 
contains email sent from FRIENDS. 

SpamKapu email address (SKE) 

An Internet SMTP*complied email address provided 

by spamkapu that Is unique to the SUBSCRIBER. 

Redirector 

Software that intercepts incoming email sent to the 
SKE, routes ft's sencler's email address to the SP for 

validation (FRIEND, or SPAMMER) 

If FRIEND, the email Is directed to the ASM. 

If SPAMMER, the SPAMMER is given an error 
message similar to one If the user didn't exist along 
with information on howto access the 
SUBSCRIBER’S WBM should further communication 

Web-bal^ln^engw (WBM) 

A Web site that designed to determine If a SUSPECT 
Is either a SPAMMER or a CONTACT. 

An online form would be presented to the SUSPECT 
to allow entry of the intended message to the 
SUBSCRIBER. 

This form would operate in such a way that only a 
human SUSPECT would be able to property execute 
the form. 

A unique wd> page wilb a nmdom word would be genosted 
The SUSreCT would be p rompte d to enter the wind. 

If die word matched, the fixm would be considered 
“operated by a hvanan” and the SUSPECT is now deemed as 
aCXlNTACT 

If validated as a CONTACT, the meesage in the form 
along with the CONTACT’S email address would be 
sent as a special email to the SUBSCRIBER’S ASM. 
The subject line of the email would contain the word 
"contact:” so it could easily be fittered or be sufafect 
to special processing by an industry standard email 

fttlF^BSCRIBER would have the opportunity to 
read the email, knowing that at least It was sent by a 

CONTACT. 

ASL manager 

Software that Intercepts all sent email from the 
SUBSCRIBER and copies the recipients along with 
other Information Into the ASL 
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The ASL manager may work on either a dynamic (aa 
emails are sent) or batch (analyze logs or other data 
sourcBs). 

The ASL works in conjunction with the UMM 
SMTP manager 

Software that provides a SUBSCRIBER with an SKE 
and Interfaces with other Internet SMTP standard 
functions such as: 

Setufiog email FROM or TO the subscriber ifaroi^ Ok ASL 
manager. 

For exanq)lG. Ifae SMIT manager may mterftce wiOi Ok 
subscribers ”oGQcial'’ or knofmiooipmate address to 
eliminaK spam sort to Ok corporate email system. 

User maintenance modules (UMM) 

A set of software utilities that allow the SUBSCRIBER 
to maintain personal settings and the ASL Examples 
include: 

Default expiration settings. 

Bulk4oading of frtends into the ASL 
Saarch/addfedKfdelete ASL entries 
Handling of mall once sent to PSM (l.e. creates 
predefined response to the spammer) 

Outright rejection of email, disallowing it to even get 
to the PSM. 

Preview/Delete Items from the PSM 
Other features of benefit to subscribers 
SpamK^u may be packaged In a variety ofwaya 

As an online service (l.e. Web site) that allows users to 
subscribe and realize the benefits of spam-free email senrtces. 
Asa server-side software package. By installing SpamKapu at 
the sanrer level. users with a valid account on the server 

can receive the benefits of ^m-free email. This is an idea 
solution for ISPs and/br larger organizations with their own 
server resources. 

As a dient-side software package. SpamKapu can install on 
popular emad dierrts such as Outiook and provide near-identical 
functionality. This is an idea situation where the user's server 
does not have SpamKapu installed 
Operation of the Invention 

As a server-side sdtware package or online service 

SUBSCRIBERS are added to SpamKapu system. 

Each SUBSCRIBER is provided with a PSM, ASM, 
and UMM and an SKE. 

The SUBSCRIBER changes appropriate setting on 
their email software to accomplish the following: 

Use current Intnnet standards (cuirratty POP3 or IMAP4) to 
letrievo mail fron bofli tbe PSM and ASM 
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Redirect email sent to their cancnt esuil address to dieir 
SKB instead OR set tte email address to ftdF SKB. 

Use tie SMTP manager to handle die soiAig of aD emaO. 

Any email sent to the SKE is processed by the 
redirector as described above. 

Any email sent by the SUBSCRIBER through the ASL 
manager (via the SMTP manager) and processed as 
described above. 

The user can retrieve email from the ASM at any time 
using Internet standaids (currently POPS or IMAP4). 

The user can retrieve email from the PSM at any time 
using Internet standards (currently POPS or IMAP4) 
user other software that can delete, further fliter, or 

altogether discard the contents. 

SUroCRIBERs may interact with the UMM at any 

time. 

Use of SMTP>standard email error response codes as 

a matter of rejecting user-epedflc spam 

Ths b bong iiSM tod^, m only a 9V01 email 

server is icjecdng ALL email a given NETWORK. 

This claim is against SPECIFIC emaildirected to a 
SUBSCRIBER that is identified |o have originated fiom a A 
SPAMMER. 

As a dient-side soflware package on an Outlook 98 or greater 
client 

After Installation, a folder labeled "P8M” will be 
created. 

Usere may interact With the a clientelde InetallaUmi 
of the UMM at any time. 

ASM will be sent to the standard "inbox" folder and 
PSM will be sent to the "PSM" folder. 

Other operations are similar to the seiver<side 
package or online service described above. 

(k) Claim or claims. 

Anysoftwan wMch analyses tha usw^sparsonal amall usage 
pattams to craata an ASL oraquiyatantandin-tum uses dtls ASL 
to make da^lona on how to process Incoming email. 

Analysis of sent amall and racalvad fo datwmina and rafina tha 
ASL 

Analysis and rejection of SPAM at tha lowest (earliest passible 
lav^ In tha mall transmission protocol such that SPJUUMERS 
racelva error messages Indleaang tha user doesn't even exist 
SUBS&VBER never even processes or downloads amall. 

Analysis of contact databases to determine and rafina the ASL 
Ane^f^ of email logs (boOi sent and racelvadj to determine and 
retina tha ASL 

Mediods to only allow humans to access tha WBM to sand 
massages to the SUBSCRIBER. 
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Methods for party saftwaPB to Int&tace with SPAMKAPUio 

broaden the scope and funcdonMlty of determining If email Is 
SPAM or not, for example: 

Analysis against 3” party databases such as the Better 
Business Bureau 

Methods for 3^ party software CO tntarface wldt SPAMKAPU to 
broaden the scope and functionality of the various types of 
actions that can be taken on SPAM. 

Methods for 3^ party software to Interface with SPAMKAPU to 
broaden thescopeand functionality of anMysingpowm’ 

(l) Abstract of the disclosure. 

(m) Drawings (If any). 

(n) Execute oath or declaration. 

(o) Sequence listing (if any). 

(p) Plant Color Coding Sheet (applicable in plant patent 
applications). 

Other 

4fgt9flCWCiQVWMli9yMt»m 
— rvr-fr— ptffcftWpcftmi ofsyvtem 
etfpll^baMC^ mohHMctam of sfrtam 

UstofothMTldMMm swtusMM ofthMsytsiom dm^rtrfaocot <o dothesJimM tfUng fotfierttan 
spgmntbt^ 

references to other techm^ogy used 
RFC 821 
SMTP email 
PERL 
Sendmail 

RealTime Blackhole List (www.mailebuse.ocg) 
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SpamKapu" detailed operation of SPAM PROCESSOR 
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"SpamKapu" detailed operation of SPAM PROCESSOR DATABASE 

Confidantfal Information. 

Tills doGurnom is the property of Cyberl^ Ina and serrt under attorriey^cGvdpnviedge. 



Using FROM email address 
Buppliedi loop through each 
Dneof the A3L unti there is a 
pattern match In this field 



Once there is a 
pattern match, 

I execute the condition 
baaed on tho code In 
this field 




If the condition reluma TRUE, 
execute the action based on 
the code In thia field and exit 
If cx>ndidoti returns FALSE, 
continue looping through 
each email pattern 




^ecute' 



g 



0 



p 

u 

3 

9 

3 

3 








MBS 


^WendT^^" 


■ ' 


this is mv mom so she's alwavs a fHend 






acthrerar 

{mnsoty 

6^/2004 


36 1 
1 


hlend 




I'm working with this businessperson only frem 
Feb 5 to June 6 




ne.com 


before ' 
(12/1/20C 


m 


fftend 




After 12/1/2003, 1 do not want messages from 
thte address 


’laaolcnml 


always 


email (SPAMMER, 
‘noaoLtxf'll 


emaa we get from aol gats send back with an 
exDlanationI 


» 


blackholeO 


emalltmother (SPAMMER, 

blacMisltxt, 

abuse®%domain% 

%SENDER%, 

adminiffisDamlcapu.com) 


run a 3rd party software, mark as a ^lammer, 
send a standard massage to the system's 
administtatar, and mark It as coming from 
spamkapu’s administrator 


tr 

■ ^ 


acdverange 
(3/14/*. 3«onl 


friend 


my birthday falls on 3/17, so from 3/14 to 3/20, 
I'll lei anyone pass through to wish me a 
happy birthday.l 


• 




enormsge(spammer, 
oontactbd 550) 


mafic as spammer, send the "you might be a 
oontacd* message, return "No such user enoT| 
code 



a»cut 



condlUoni 8ynta»| 






iactivefanqe 



rynppde 



biackhoie 



before 



activerenge (low ! 
date, high datell 



Condition Table (example) 

description codej 

return Iroealwavsl 



funcodef filename) 



bladcholeD 



befbrefdate) 



5335iiIi!I53 



Inie if today bwHhinarancBi 



runs long and lerqitli/ code 

prpflraiit 



3rd party software to check 
agalrat a biackhoie bt 



true If today la leas ttan date 



Action 



iftoday>=%1 and today! 
<=%gthenretumftniB)l 



|exBC(roe.pD 



exectblackhola-arB] 



if today <= %1 then 

returr^ftiue) 



email 


emaiftldenL file) 


return pannl as identifier, get 2nd parameter as a 
filename, translate and email H. 








external 


e)CBcffile)l 




emaartn 


emalltmother (Ident, 
filename, to. from) 


return pannl as Identifier, get 2nd parameter as 

filename of message text, send It as an emaB to 4th 

parameter, and use 3rd oatamatBr as n»nu 




r«um(8PAMMERY 

rah im/ODAmJCn\ 


1 > rT r-1 g I i R h 1 > JltiiJ »iiL i i iki 1 ■ 

























"SpamKapu" detailed operation of ASL Manager 

Confidential Information. 

TTiia document is tie property of CybeiOom, oTKl aent undw ollerncy-dient 



Content arrives into 
thoASL*Wfrwna 
variety of wuroea and 
eagfllylnoorpot a t B a 
3rd parly pluglra 

• 'TbadaBsicflramplais 
ofoourBoaroomai 
addreoaeo sent 
toandioodvedftom 
to SMTP Merttear. 
hcKwamrldoosnl 
have to atop there. 
There are a wide 
variety of other 
sources from which 
emaDedckenasmay 
begtanod 
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After content bee 
anrfvod eHhor oiv 
demand or vie 
schedUbtg, the 
rulee processor 
determines how 
to add or 
modtythaASL 



IhaASLMdloo 
oanbopopulotod 
by any on- 
demand or 
schsdiiad 
process ft 
oontaVis a very 
rich Nslory of the 
SUB8CRBTO 
avaBUsfbr 
enatysis. 



ASL Manager 



ASL orvdemand prooeeeor 



i 



I 



f 



H 



ASL scheduled procbinor" 




ASL Rules ftrooeaa o i 



AakAensger Rules Ob 














ASLMafLog 




3rd Party appe 




3rd Party dbfo 




The ASL Manager aleo 
runs tasks ona 
scheduled basis for 
analysis and 
maintenance functkm^ 
This allows a very rich 
emn^naSon of the 
SUBSCRSB^ASL 
dat a bas e and mail log to 
oonthmOyrafinethe 
datebese accuracy and 
rslsvanoa 



Thesystsrr's 
archaecUeeitowsfor 
easy integration of 3rd 
party soUions so 0»t 
SpvnKapu oon hemess 
the oollBcthe power of 
thehdustjylo 
oondnualty extend and 
Improve to feature oet 



The Utimefo resort of this 
archdectuPB is to create 
9 very richly detaaed 
ASL database which 
goes beyorfo total 
titfrtoation of apam by 
oantirMaty reAsctfnQ the 
caaient neadb ofthe 
SUBSCRBm dynamic 
useofemal 
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"SpamKapu" detailed operation of REDIRECTOR 



Typical operation of SNTTP "send email" process 



Scnds^GMTP 



RequntConnecdon 



bop and sand nsKt 
recIplBrtanifiii BklreBs 



Raoetw^WTTP 



Aooept 

Connection 



oonfimn/UenyabUtylD 
|XDoasB rec^dent 



TVpbaPy, the itandard 
coni mia ikyipartkwTiedtea>npV 
based on whetfieror not lha 
user Odets or whether or not 
' the SMTP nsoeivo' has the 
authority to jarooeas amefl for 
thfi user. There very GUto to no 
oUlV ponuintoa* 



Confidential Infomiation. 

Th's document is the 
property of CyberCom, Inc. 
and sent under attorney- 
client piiviledge. 



Send msasaoe body 
end mark end of 
messaoe 



sand maaBapalo one or 
morefadptonts 



Atthto stagoi wars era goino to 
- gat this email to Ihefe- standard 
tnboa. 



QIpamKapu-modified operation of RECEIVER<8MTP 
process, known as the REDIRECTOR 



SwdrSMTP 



Request Connection 



Reooivar-SMrP 



Accept 

Conrwtion 



Spam Piooeasor 



At this tova) wa ara dotnQ 
exsctiy what a alandard SMTP 
faoaiver would do: either reject 
or aooept a given radptom 
address. 



loop and sand nsDd 
racfotont emal address 



Store *FROMT addPBSS 
for taler use. 



parform SMTP fidustry- 
standard oonttonation. 



normal a coe p t ta i oa ^ 



Its redpleni would hBva”noimaiy' 
baan aoceptodl toe SpamKapu 
prboesa toon takes OMBir 



Send emafl addraas of 
PFCMandRBCmfT 
ta qu^ i denWtcatto n 
from spam processor 



Return I d eid lflLBtkjn as 
FReO or SPAMMER ar 
Booompar^ error 



cfipianeo Bi rnora 
dataH alsawhere 



ambad toe error tneaMgo 
pasMd from the SRAM . 
PROCESSOR 



R»0 SRAMR/ER 



Confrm Reject 

abiEtyto abD^to 

prooesB prooQse 

raopreni raopient 

entaD emel 



At thtataval; SpamKapu has 
raoDgntaed the aender as either 
SPAMdS^aFHBMX fmSHD, 
then raototant (SUBSCRtBS^) 
oma9 addrasa to oonffamed as 
vaDd, otoenfvtoa, «i error 
meseagebratomed. Thecxaitont 
of too error massage providae 
tostrucdons to the user on how to 
aogesitoeWB Mand estBtottoh 
themaelves BB a FROO. 



Send meaaaga body 
andmaffcandgf 
massage 



aand message to 
radptanto identi^rg this 
eanderaaFROO 
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SYSTEM FOR ELIMINATIN G RUECTRONIC MAIL 



This U.S. pstent qiplicatioii daims the priority of U.S. Provisional ^licatioD 
60/1SO»02S, filed on Sqnember 1, 1999, entitled "Unwanted Email FUtering Syt^", and U.S. 
Provisional Applicatioii.60/180,937, filed on February 8, 2000, entMed "Unwanted Emafl Filtering 
System”, both by the same inventm'. 



FIELD OF THE INVENTION 
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This inventicm relates to a system for eliininating unwanted email, and particulaily to 

one in aiiich all email must be recognized as seat by an authorized sends- in order to be accepted. 



BACKCaiOUND OF THE INVENTION 

Unwanted or unauthorized email is a significant bane for users on worldwide 
networim, «pich as the current public tatemet Once a person's email address becomes known in a 
netwmk system, it can easily be replicated in computerized lists and passed on electronically to an 
unlimited munber of parties who have not been anthoiized or invited to send email to the vea. A 
user’s electnmic mailbox can become inundated widi such unauthorized email. Unaudioiized or 
unwanted is refened to genetically in the industry by die term "spam", although dm term is 
not intended to be associated with or to disiurage the popular canned meat product sold under the 
trademaik "Spam” by Hoimel Coip. The user may have an email address with a commercial 
iTi fiifitifltitiii service provider (BP) service -^ch liniits the amount of email that can be accepted 
and/or stored or which diargea the user by die volume received. The user may also waste a 
aignificflnt amount of tune opening and reviewing sudi unwanted email Unauthorized email m^r 
also be sent by vnscnqrulous persons who may enclose a virus or rxndous software agent in die 
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wnni i wliicb can infect die luet^ compoter qrstem, or^xdiicb can be used as an u n an di orized point of 
eoliy into a local netwoik system that handles the user's eaudL 
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Most, if not all, of the cunent software to control the receipt of spam is based iq>on 
die use of identifying lists of known q»m sources or senders ("^ammeis"). Such conve nt i on al 
spam control software fimetions on die basis of receiving all email as audunized unless a sender is 
jitwitifiiwi as being oo the CTclwsip" list and die email can be filtered out 11118 approadi is only as 

good as the idenfifying list and cannot gunanteothst die user will not receive spam. S pammer lists 

retjuire fireejuent and must be distributed in a dmefy manner to all subsenbers to the spam 

control software or service. Sophisticated qranuners fiequently change thdr source hatemet 
Bddf Tffff, and can defeat a t te m p ts to keq> exclusion lists current Th^ can also route the unwanted 
nmnii dnouB^ the hitemet servers of odier parlies so as to disguise the source of die emails through 
ititiftffiinna or populafty recognized names. A user's email address may also become known to large 
numbers of individuals in public «*■* rooms or on public bnUetin boards. Unwanted emaU sent by 
individoals are not traoked on spammer lists, because the sending of email by individuals is 
technically not qr a mmin g. 



SUMMARY OF THE INVENTION 

Accordingfy, it is a piincfeal object of the present invention to provide a spam 
ctmtrol system that cannot be defeated by spammeis who fiequently change their source ad dr esses 
or themselves by routing through other servers, or. by individuals who send email 

that are not invited or authorized by the user. It is a particular object of the invention diat die 
system of fee invention reject all email aa unanfeorized unless the sender is recogn i zed as being on 
the user's accqMance list 



ha accordanoe with the present invention, a system ftir ehminating unauthorized 
email sent to a uaa on a network eomprisea: 
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(a) aa mw l diwit for. allowing die user to receive email sent on the netwoifc 
addressed to a unique email address of die user, 

(b) an emailHreoeiving server between die network and dM email client 

for receiving email addressed to the unique email address of die user, said cmail'-receiving server 
having an «n»Winid senders list (ASL) module wliidi maintains an ASL list of email addresses of 
external users authorized to send email to the user, and 

(c) an email r ejection module operable widi the ASL module for rejecting die 

reodpt of email to the email address of die user if the email kldress of the sender is not one diat 

is maintained bn the ASL list for die user. 
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In aprefenod embodhnent, the system's ASL module codudes an ASL database for 
storing ASL lists of authorized sender addresses for respective subscribere of the qwtem. a qiam 
piP fif gff y r for the ASL lists for matches, and an ASL man a ge r for creating, 

and iqpdating the ASL lists, A redirects module rgecta emafl it, vpm sending a 
request for vaKdatioo to the spam processor module, the sender's address does not ma t ch any 
authorized sender address found cm die ASL list. Email rgected by the redirector moduk is 
redirected fo awd>*based mwaMig in g (WBM) module which sends a message DodQdng die sender to 
confirm the sender is a legitimate sender of email to the intended ree^ient If the sender logs 
on to their status, the WBM module executes an intersction procedure which can only be 

by a boman, in order to ensure diat die confinnation procedure is not perfoimed by a 
mafftmTik -at program. The ASL manager maintains the ASL lists based upon sender address data 
collec ted fiom various sources and analyses of various email usage foctors, including sent email, 
reorived contact lists maintained by the user, user preference inputs, third party progiams,etc. 



The inventiem also caicampasses associated methoda of perfonning the above 
fonctions, as well as related software components which enable these functions to be performed. 



Other objects, features, and advantages of the present invention will be described in 
further detail below, with refi^ence to the following drawings: 



- 3 . 




BRIEF DESCRIPTIQN OF DRAWINGS 



FIG. lA is a blodc diagram ittustratiiig a standard IntemM email system asing flw 
conventional mediod fin filtering gmali fiom qtammcn (Prior AitX as conq>ared to FIG. IB which 

riiows a conccptaal ovehdew of a system in accordance wifii file present invention. 



a 

O 

tn 

m 

mm 

CO 

CO 

o 

Ml 



C3 

CO 

ru 

in 

a 

C9 



FIG. 6 is a process flow diagram iUustreting the detailed operation of a Wd>*Based 
Messenger (WBM) routine for handling email initially rqjected by file anti-qiam cMboL 



FIG. 7A is a block diagram illustrating a standard SMTP se^-recdve email 
handling process (Prior Art), as compared to FIG. 7B whi^ shows a modified Redirector process 
for handling received email. 



FIG. 2 is a p roc ess flow diagiram fi^r a preferred embod iment of the anti^iam 
system of the present uiventioiD. 

nG. 3A U a block diagram flhistrating a standard SMTP send email process ^or 
Art), as compared to FIG, 3B which shows a modified send email process, used in the present 
invention. 

FIG. 4A is a bhxdc diagram illustrtfing a standard SMTP receive mail process 
(Prior Art), as conqmied to FIG. 4B whidi sho^ a modified receive email process used in file 
piresoit invdition. 

nc. 5 IB II process flow diagram illustratnig the opefation of an rati-^pam 
processing routise in the preferred embodixneiit of die invention. 
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V1G. 8 is a BcbeDutic iihutjatiiig tfie slnictiiic ufjcratioa of the ASL 

Manager in tile piefiated embodiineiit of die q>ain coittol system. 

FIG. 9 illastrates a detailed isqilementation of examples of piocesnitg of e m ai l 

send/teceive and user contaet data into specific finms of actions taken by dm ASL Manager. 
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DETAILED DESCWPTION OF INVENTION 

In contrast to the known qiproacbes of eadsting qmu control methods of accqtting 
all unless listed on an exclusion Est as unauthorized, the fundamental prini^le of die present 

invention is to rgeet all email listed on an inclusion list as authorized, hi this manner, it is 
pffffiri h lp to filtcx out wnMl diat comes fiom unrecognized spammeis as well as individuals who send 
ffniiii that is uunvited by the user. Unlike the known email filtering systmns, the present invention 
does not attempt to filter out die unwanted email after it has been acoqited. Father, it outright 
ngects file at the earliest entry levd. Thus, the invention operates on fiie ptemise fiiat all 

email will be treated as unauthorized unlesa tl» sender is found to be on an "aufiimized senders” list 

in Older to be accqrted by fiie user. This provides an inherently powerful and 100% efifbetive q>am 
con trol sohilioa in an environment where spammers can instantaneously c h a ng e their source 
or qiparent identiQr and individuals in public areas can obtain email addresses of other users 
and send them unwanted email. 

The following is a detailed description of pne preferred embodiment of a system for 
implemeoling the inveation coneqH. hi fids embodiment, the qiam control system intelligeatly 
formulates the "authorized saiders" list based upon an ongoing analysis of the user's email usage, 
such as to whom and with what firequency sent email is addressed to other users, and through the 
g fltifpring of high-level user contact data, such as a user's known contacts and associates identified 
on other lists or files maintained by the user whidi indicate persons considered as authorized. The 
"authorized senders" list may also be updated and manipulated by the user at any time to add or 
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leinoveanlliarizedsendetB. While dns q>edfic inq>lancatatioii is used, and certain otmpoaasia are 
Itfovided and configiired to be in t er op erable in die described ways, it is to be underatood that die 
iiill scope of the invention is deemed to enconqMss many other suitable modi fi ca ti o n s and 
variadons to the described guiding principles of the invention. 
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HG. lA is a Mock diagram of a standard onail system for sending and recraving 
enrmii oo di6 Intcmet and is used to oqilain die conventional method for filtering out e m a il fiom 
spammen. The system follows a standard industiy protocol fiir handling email cm the Intemet, 
refttied to as SMTP. Uscats typically subscribe with a cboseu ISP for hatemet access and relat^ 
services, tn«in<fmg email services. The usen access the fotemet thiou£ili the ISP u s i n g a diahqi or 
}iigli*q)eed line connectioa and a standard browser. The browser includes or ftmetions with a 
standard client 101, andi as the OufioKde '^ email client distributed ^ Microsoft Cmp., 
h faxtq m nrt w rwH m'BeIlevue,'Wariungton, oc the Netscqic ™ onail client n^ by AOL/Netscqie, 
headquaitend in Fairfox. ^rgmia. The ISP operates at a website address conreqwoding to its 
Hiwnain timne wbirii is a^iEssable by US6I8 on tbc Internet. Hie ISP's service fimctious are 
peribmied for a large rramber of subscribers through one or more serverB. Typically, an email 
server 102 is used to handle the email service fiinctioiis. Email sent to the ISP fiom the Internet is 
received at SMTP Server 102b, where various administiafive fimctiaiis are performed, sudi as 
^»h««ifing whefin- foe addressee is an authorized subscriber of die ISP, tiien the email is placed in a 
storage qiace reserved fin that user, lefoned to as hibox. 102a. When users c oiin e ct to the ISP, they 
can retrieve foor email and store it wifo dieir own emsjl client (on their own oompiiter). Users can 
sen d ^mail by coimiosing it loealfy at foeir email client, then uploading it to foe SMTP Server 102b 
at foe ISP, which then routes it to the ledpienf s email address on foe Intemet 



25 Conventional anti-spani control can be inqileuiented wifo die SMTP Server and/or at 

foe email client Many ISPs mqilanent an exclusion list of known spammers at foe SMTP Senrer. 
In addition, foey commonly allow a user to filter out unwanted email fiom certain senders known to 
foe nsa*. For exanqile, the user's email client may have a filtering fimetion that allows the user to 
input unwanted sender email address^ to foe SMTP Soyct so diat email received by the SMTP 
30 Server can be filtered out before being put into foe user's Inbox. Ftofoer, indqiendent software 
vendors sell sophisticated email handling programs diat work wifo foe user’s email client For 
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ex8nq>te. bandling program have fonctioiis for cafogrmzing received email into topical file 
foM mft «tom 1 fitma muecognized sendcw may be put into a "Miace H a n eoW or "Uaiccognized" 

file folder. 
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5 In FIG. IB, a coacqrtual overview, of a system in accordance wifli the present 

favention is shown. As before, the standard email cHont lOl is connected to an email server 104 for 

and receiving to and Horn the Interne t via SM1T Server 104b and fiibox 104a. 
However, in this modified CTnali server 104, an Authorized Sender List (ASL) Manager cqituies 
leceipieiit addresses fiwm email sent by flie user, as shown at block 105, and also c^tuiw 
10 B fn d ffr email addresses from sent to fite user, as shown at block 106. The ASL Manager 
analyzes the 

defined rules (described in further detail bdow) to add or remove email addresses from foe 

"authorized senders- list, referred to as the ASL List or l>itabi«^ The ASL List is used by foe 

SMTP Server 104b to accqit only email finm senders on file ASL List and place file accepted email 
15 in the user's Inbox 104a, while rgecting all other email as "unauthorized-, as indicated at block 107. 

Referring to FIG. 2, file process flow fbr the operational steps of foe anti-q;>am 
system of the present invention wifl now be described. Certain tenns used in the desenption are 
definedbdow: 

20 

SPAMKAPU: An cxanqile of foe qpam control system of the invention. 

SUBSCRIBER: A person subscribing to an ISP anail service that is using the spam control system 
of the invention. 

FRIEND: An email*8endmg source fiiat is aufiiorized by foe spam control system to send email to 
25 foe SUBSCRIBER. 

SPAMMER: An eman*seaiding source that is not authorized to send email to foe SUBSCRIBER, 
which is commonly understood to be an urdmown or unauthorized party that is using a manual <xr 
computerized email list mailing program to send large volumes of e mails repetitively through the 
Internet. 
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CONTACT: An anail-seoding source ftat has been identified by the system as ^legitiiBate 
conespondent of die SUBSCRIBER is anthoriwd by the systan to sand email to the 
SUBSCRIBER. 

SUSPECT; An sending source flial has not yet been identified as either a SPAMMER or a 
CONTACT. 

Pmati sent fiom the lotemet (103) is sent to die email addies of ttie ISP fin die 
SUBSCRIBER, refiaied to in block 201 as die SpamKapu Email Address (SKB). Received email 
must first pass dnoogh dio Rediiector 202. The Redhector 202 s«ds a request fi»r validation fin 
the "«"«i fiom the Spam Processor 203 \i*idi maint ai n s the Spam Procesong Database (SFDB) 
203a, including the Authorized Senders List (ASL) 203b. The SPDB Database and ASL list are 
die heart of SPAMKAPU, as they oontain the lists of persons authorized to send email to the 
reflective SUBSCRIBBRS of the system. The Spam Processor 203 sends a leqioase, either diat the 
sender's yiWwp M on die email is not audioiized on the ASL List, ie., is a SPAMMER, or is 
on the ASL List, Le., is a FRIEND. If the response is diat it is a SPAMMER, the 
Redirector 202 rqjeets the emaU, as ahowii at block 204, such as by sending a standard error 

message to die smding server that the user aa addressed does not exiat 

As a refinement to die system, a Wdi-Bascd Messenger (WBM) process st block 
205 may be set up to provide a corrective procedure in die event that die rejected enuni is fiom 
som ro ne not authorized but not listed pennanently on the ASL Ust as a SPAMMER. The 
iir nmHinriTwi msy actnally be fiom a person vriw has not been previously processed in the 
and-q>am system but who has a legitimate reason to reach the SUBSCRIBER. The WBM process 
205 is set up 88 part of the fwin control aysten to which die npected email is redirected. Upon 
receipt of tho redirected email, die WBM process stores it in the WBM dotabase, a ssigning die 
email a unique ID code and also an expiration date. The WBM' precesadien sends an enor ieqponsc 
y nmii to the email Sender, vdio is now treated as a SJUSPECT. For example, ^ error mms a gp may 
read: 

"An onail sent by you to SUBSCRIBER'S address was redirected to this site 
as being sent fiom an unrecognized sender address vdiich may be a source of qpam 
fimai i- If yon would iiif« to confirm yourself as a person with legitimate reason to 
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reach the SUBSCRIBER, please visit the WBM site (or scad a reply en^ and; 
confinn your status as a CONTACT.” 

The WBM may have a sqnrate wdt she address for intetactions with SUSPECTS, 
5 ■ or it may be set to receive and recognize email reqMmses fiom SUSPECTS. When a SUSPECT 

receives die enor response' gwiaii, jf flicy are a Intimate CONTACT fiir the SUBSCRIBER, diey 

' may elect to go to die WBM site m: send a rqply email in order to confirm their status as a l^himate 
CONTACT. If done before the eoqnratiao date, die WBM process will add a special codeword such 
as "contact:” to the sub|ect line of the redirected email, as shown at block 206, and re-nnite (he 
10 email to the Audioiized Sender Mailbox (ASM) 209. The sender address for email re-directed 
through process is also stored (as indicated by die d a s h e d line to block 210) and logged for 
finther anatysis by the ASL hfonager 211, to determine if the status of tbe SUSPECT should be 
upgraded to FRIEND and added to tbe ASL 203b. If the SUSPECT doea not respond, this foct is 
tn also sent to die ASL bfonager fiir finther analysis. The extra confirmation stq> effeedvdy 
IQ 1$ fiimitiatHB .SPAMMERS smcc they use automated moerams to send out batch email and typically 
W willnottakehumanresponse tune to logon to die WBM site ox send a reply email to confinn their 

O 

legitimate status. 

li 

O 

(0 If^e Spam Processor sends a validation response diat tbe sender is a PRIEND, then 

[fj 20 the Redirector 202 passea die «wail to die SMTP Receive Manager, at block 208, whidi perfmms 

O its administiadve function of diecking die SUBSCRIBER'S status and storing tbe email in ASM 

C3 

209, which is the SUBSCRIBER’S hibox. The user can now collect their e m ai l fimn the ASM 
Inboot (using standard Internet protocols such as POP3 or IMAP4) through tbe user anail client 101 
on their computer. Tbehr email is 100% spam-fipee^ since all email fiom senders not recognized by 
25 the ^em as autborized has been rejected. The SMTP Reedve Manager 208 is also configared to 
log die info nn^m* of receipt of die email fipom a FRIEND and send it to the ASL 203b for fiirfoo- 
analysis, as indicated at blodt 210. 

Users send email composed on and sent fiom tbe email client 101 via standard 
30 SMTP protocols to the ISP^ email server. The ISPs SMTP server is reqioiisible for providing 
users with email addresses within the (fystem, a^ sendmg users' email to die reetpients* email 
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addresses on flie tatemet 103. In fl»SPAMKAPUiiiv«ati<mBy8tem. an SMTP Send Manage 212 
is piovided to intarvcoe in the usual send email process. The SMTP Send Manager 212 copiea 
header infonnatioo fipom all ontgmng email and sends the d at a to the ASL Manager 211, flioi sends 
die on to its intended destination. The ASL Manager 211 performs one of the key functions 
in die invention system. It analyzes the header data titan sent email and data from other data 
sources 213 mamlainod the ISP email serv» system, such as email logs and usawsiqipM«l 
On the basis of its analysis routines (to be described in fhrthwdetad bdow), the ASL Manager 211 




data on senders authorized to send email to die SUBSCRIBEIIS. The SPAM1UU*U syslau also 

inchides User Maintenance Modules (UMM) 214 wliioh allowB the user to interact with and vplo^ 

user to SPAMKAPU for forther customizatiwi of SPAMKAFlTs email opoatims for 

the user. 



Refening to FIGS. 3A and 3B. a tttandard SMTP send email process (Prior Alt) is 

shown compared to a modified send email process used in the present mventitin. In die standard 
send process, in FIG. 3A, email sent fiwn die user's email client to the IWs email server taay 
be pre^nocessed, sudi as diecking for correct syntax, alias expansion, etc., and to identify die list 
of recipient addresses (could be 1 or more). The server email manager gets eadi recipient 
email address in turn and attempts to establish a connection to the desti n at io n SMTP server and ^ ^ 
verify if the recipient email address is proper. If negotiation is unsuccessful, an error messa|g^ 
retumed to the sending SMTP servw. If n^iotiation is successful, the sending server sods dm 
n Hffffflgii body to die destination server end perfoims a proper "close oormeclion" operation. In the 
modified send email process of die invention, in FIG. 31^ the e mail sent frorn the client is pre- 
processed, recdpieiit(s) are indentified, and coimection(8) widi the d es tinati on seivet(s) are 
as usual, l^pon successful negotiatioii. die SPAMKAPU SMTP Send Manager 212 
copies the mic emfr i recqiiait email addiess(e8) and sends the data to die ASL Manager;211. On 
the assumption that the SUBSCRIBER anthorizes' email to be received from any person the 



SUBSCRIBER has sent email to, the proper email addiroses of persons to whom the SUBSCRIBER 
has sent email are added to the ASL List of persons authorized to send email to 'tiie SUBSCRIBER. 
The sent email d«ra can be used in further analyses by the ASL Manager, e.g., to upgrade aperson's 
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status frmn tompoiaiy to perauneot if more ttian s tiitediold number of e m ai l is sent by 
be SUBSCRIBER to dw same posoDo. 
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Reftning to FIGS. 4A and 4B, a standaid SMTP receive email process (Prior Ait) is 
5 shown oonq>ared to a modified recdve email process used in tfae present inveotioD; In die stamlard 
receive process, in EIG. 4A, «nwl is received by tfae SMTP server fiom sender sources on 
die Internet and the server stores the email in the usef 8 InbOK. in die modified receive email process 
of the invention, in FIG. 4B, die received email is subjected to processing by die Redirector 202 to 
detennine if the sender^ address is that of an autborized pawn on tfae ASL List andmrized, d» 

10 SMTP serva stores the email in the user's bibox after the SMTP Recdve Manager 208 cultures die 
sendet'^Saddreas on the enuil in tfae address log stqi 210 to be sent to tfae ASL Manager 211. Even 

dw^gbiW sender is already on die ASL andiorized persmis list die lecdved email data can be used 

in fiudier anafyses 1^ die ASL Manager, e.g., to upgrade a peiaons authorized sta tu s fiOm 
tenqioniy to permanent if ftom person is reodved on an ongoing bads andbas not been 
IS changed by die usa. 



La FIG. 5, a process flow diagram illustrates die pperatioa of the Spam Processor 
203. At block 501, a request fiom the caUing routine, here Redirector 202, seeks validation vdielher 
a received is fiom an authroized sender. The request identifies die parameters wbo the email 
20 is FROM and vriio it is scot TO. The Spam Processor 203 uses the TO address to lookup that user's 



30 



ASL list 203b in the SPDB Datdwse 203a, as indicated at block 502. The lookup procedure 
follows a loop 503 of reading die next ASL record on die user's ASL list, checking for a match to 
die gnail FROM address (audioiized person), reading tfae next record if diere is no m a t c h of the 
current record, executing the matdi condition by issuing a TRUE value if finmd, ottowise 



25 




oetuuieo . 

, the returned value 18 sent as a ^^a^^^tb^callingroutiiie,i.e., the ^ 
Redirectm^ 202. If the r ati « ni wd v s h i e in SPAM14BR; ' »etaadard a irnr m e ssage is lU CltlflBd. As a f/pf/dt) 
( tpfrnit optfon, if no ASL list is found fot the user, the system returns the value FRIB^, as 
at block 507, in order to allow die email to be accqited as a temporaiy condition until an 
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ASL list C8D be established for that user. He request pro ces s iiig routine can be inqdcmented using 
industry standard PERL prograrruning syntax and incorponting a PERL intopieter to execute the 
{Hocessing niles. 



In FIG. 6 , 8 process flow dugrain iUustiates the detailed operation of the Web-Based 
Messenger (WBM) routine for handling e mail rejected by the Redirector 202 ,(866 FIG. 2). 
Preferably, tire WBM process is irriplcinented via intoraetion with a rqected sender at a separate 
Web site address. Ih Phase 1, conreqranding to step 204 in FIG. 2, foe WBM process is initialized 
at block 601 by the ASL role letuiiirng a value fin rgecting an email as sent fiom a SPAMMER by 
foe Redirector 202. At block 602 , a unique ID nuinber is a srig^y* h s email in foe WBM 



^fataiimg. and a given eKpi ratim i date is set, e.g.. 48 hours. At block 603, a return roeasage is added 
Hopg with foe unique ID code to tire body of the SPAMMERS email and sent back to the sender's 
email in order to noti^ the SPAMMER to go to die WBM web page if foqr widi to follow 

through wifo contacting the SUBSCRIBER. The WBM then waits for the SPAMMER to go to tire 
WBM site to complete the p ro c es s , referred to as Phase 2. At block 604, the SPAMMER accesses 
foe WBM web site and agrees to tire displayed terms and conditions of usage. At block 60S, foe 
WBM process verifies foa* the time firr reqxmse firr foe email conespondirtg to the ^ nurrrber has 
imtexpired. The WBM foen follows a test procedure to ensure that foe reqxmding SPAMMER is 
not by a mf-riinniraii pro gram. For example, at block 606, a word-stylized m 

non-standaid find can be di^l^ed as a gnqfok image, and at block 607 the SPAMMER is 
prompted to foreword that appears in the gnqphic. A mechanical program would not be able to 
read a graphic image of a wmd in unrecognizable find. At block 608, if the WBM process 
tiiat a correct word has been typed, foe SPAMMER'S status is upgraded to SUSPECT on 
foe ir8er*8 ASL list At block 609, the WBM process presents a form to enable the SUSPECT to 
enter a short message to be sent to the SUBSCRIBER For example, foe SUSPECT can adc the 
SUBSCRIBER to mate sure the attti-spam control has been iqrdated to allow enrail. At block 610, 
foe email and message is seirt, by routing directly to the ASM email box for foe SUBSCRIBER 
along with modification of the header to include a codeword or flag, e.g., addiitg the word 
"corTtact*” to the subject line. The codeword can be discerned in foe ASM email logging step 210 in 
FIG. 2, in order to difiBnentiate the redirected email from other email determined to be au t horized 
email. Atblock 611, the SUBSCRIBER can now read foe SUSPECTs email. If foe SUBSCRIBER 
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sends a reply to the email, the SUSPBCTs status may be automatically upgraded to FRIEND, or the 
SUBSCRIBER may iqigiade flie status to FRIEND manually by intcractian with tiie ISP email 
server doon^ die UMM 214. At blodc 612, if die SUBSCRIBER detennines diat the email is from 
someone whoso email should be rgected widiont a WBM enor r^ly optum, the SUBSCRIBER 
may opdonsUy downgrade the status pexmaneody to SPAMMER dirou^ die UMM 214. 

Reftning to FIG. 7A. a blodt diagram illuBtrates a standard SMTP send-ieceive 
Bfnaii hmutiing piocoss (PiioT Art), as Compared to FIG* 7B vducb shows a mo di fi ed Redirector 
process Ibr handliiig received emaiL In die standard process, the Sender-SMTP 701 requesto 
to tbc Rocoivar-SMIP 702, which aocqMs.the oomwetion if available. The Smdes 
SMTP p e iibuns die task in its Send Email loop of sending die teceipienf a email address. At 
block 703, the Reedver-SMTP confiims or denies whether die redpieot exists or whetfaa it has 
authority to process wndi fiir this user. If confirmed, the Sender^ShfTP sends die message body 
and marks die end of the message. At blodc 704, the ReccIver-SMTP reedves die message body 
and it to the email box of die r ec ipi ent (or rec^ents if the message is sent to more than mie 
ledpient at that SMTP server address. 

In FIG. 7B, dw Sender-SMTP 701 and Recdver-SMIT 702 perform their usual 
establishiiig of a connectioo and check fiir valid receqrient e-mail address. However, in this 
nyvijfiwt process inqilementcd in corgunction with the Spam Processor 705, the sender's FROM 
address is stored by the Spam Processor fiir later use, as indicated at block 706. At blodc 707, the 
sender’s FROM address and die recipiaif s TO address are sent to die Spam Rocessor 70S, a 
request for validation by the Redirector as described previously. At block 708, after checking the 
recipienf 8 ASL list to determine wbedier the sender is authorized, the Spam Processm can letuni a 
response of FRIEND or a response of SPAMMER widi an acconqianying enror message. If the 
response is FRIEND, an ouqmt is sent to die Sender-SMTP confiniimg that die email can be 
received, and the email is sent to the Receiver-SMTP as usual. At block 709, die Reedver-SMTP 
puts the email in the ledpienfs email box and, if desired, can include a message noting diat the 
sfindff was identified on the ASL list as a fdend. If the rraponse is SPAMMER, then en error 
message is returned to die Sendor-SMIP that die recipient does not mdst or the Recipient-SMTP is 
not authorized to accept the email. Optionally, the Receiver-SMTP may send the omail through (he 
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WBM process, as described picvionsly indicated at blodt 710X if te^xmse from the ^pam 
Processor that the of the sender is an unknown sender (as opposed to having die 

confinned status of SPAMMER). 



FIGt 8. a Bcfaematic diagnun illustrates the structure and operadofn of die ASL 
r>"'Managcr, pievioi^lv described as compoiiGOt 211 with reqpect to FIG, 2. The ASL Manager 
pieferably is stmetmad to have an ASL On>Deniand Preoessor 801 and an ASL Scheduler 
Processor 802, both of uA^^intoact widi an ASL Rules Processor 803, uddeh also exdianges data 
with the Spam Processor Daah^ (SPDB) 203a. Email addresses sent to and received from the 

10 SMTP Send Manager 212 and SMH?RcceiveManagw 208 are processed by the ASL On-Demand 

Processor 801 which executes die appropriate rules in conjunchon with the ASL Rules Processor • 
803, Content ftoin a variety of other sourcm^mcluding conqiatible tbrid party plug-ins, can alao be 
pocessed to create, popnlate, and update die AilL Usts stored in the SPDB 203a. For example, 

coniem rnay be received from a T>rag and Drop for conveniently haridling iwn address 

15 iq>ul8 while working wididmemaflcUent, user addremh^^ from Web sitMudnle working with 

an browser, addresses added by die usct to a oa^ddop contact manager, sudi as die 

Miaosoft Oudook ™ Address Book, or odier coolact Usts, and^it^ address inputs generated by 

diird party software that can operate with die user's client programs. 



20 The ASL .Sdwdulei' Processor 802 is used to pocess tasks on a scheduled basis fin- 

various analysis and maintenance fimciions. This allows a very rich examination of the 
SUBSCRIBER'S ASL list, mail log, and other data files, to continnalfy refine the "audiorizcd 
sendeis" list fi»r accuracy and relevance. For example, die processor functions can include: an ASL 
Mail Log Analyzer fbr analyzing the ASL Mail Log database 803a of the SUBSCRIBER'S received 
25 and sent emails; an Ei^iiration Date Analyzer fijr setting and enfincing oqpiiaticm dates fin 
senden to be re-authorized; a Low Volume Analyzer for downgrading or e hmin ati n g the 
status of sendcia with whom the SUBSCRIBER communicates vwy infiequenfrir, a 
High Volume Analyzer fiir iqigtading or permaneady maridng the authorization status of senders 
with whom die SUBSCRIBER communicates very fiequendy; a Fuz^ Logic Analyzer for making 
30 qualitative decirioos as to FRIEND or SPAMMER status based on a variety of fectors; and other 
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Thiid Party Analyzen for analyziiig data geoented by third party phig-ins and programs to refine 
the ASL list 



The ASL Rules ftocessor 803 contains the inks (in an ASL Manager Rules 
Dahdrase) **'«»*' detennine how to add, tqxl^ or modify the ASL Lists maintained in the SPDB 
Database 203a. The Rules Processor can have an architecture fiiat readily accqrts and interoperates 
with ttuid parfy 803b and qiphcatiains programs 803c in order to harness die collective 

power of devdopers in the netwodc cmnmomcations indsatiy to condinially improve and extend the 
SPAMKAPU system's feature set The ultimate result of this ardntectare is to enable the eieatitm 
of a very richly detailed ASL database ^thidi goes b^nd even the total dimhi ati o n of spam email 
iien other or fiiture needs of users fer the dynanuo and intelhgeut handlin g of email. 

In FIG. 9, a detailed implementatimi is illustrated of exanqilcs of processing of email 
send/feedve and user ctmtact .data into qiecifie feims of actions taken by the ASL Manager. The 
basic inocess flow consists oC Step 901 of looping ttoough eadi line of an ASL list (called a Table) 
ffftmpnring die FROM addxess crptuied from an incoming email for a ma^ Step 902 of 

detamining ^rtiatever condition or status flag has been set fear the matched entry, then executing die 

coira^Nniding condition rule as maintained on the Cmufition Table, resulting in return of a Return 
Value; and Stqp 903, based <m die Retain Value, executing the ooncspmiding action rule as 

maintained on dm Action Table, and exiting widi a Final Return Value fiom this action. TofeUow 

one dirough diis process flow, Stqi 901 finds a FROM match of the sender address 

Step 902 cotcs flio expiiation date condition 'Tiefore 12/1/2003" and executes the 
"before" conditio" on the Condition Table to return a value of "True" if toda/s date iskss than the 
exjnration date, and Stqi 903 imtes that die sends'-Btatus action (if condition is True) is 
"friend" and executes the "ftiend" action on die Action Tabk to return a Final Return Value of 
FRIEND (no parameters neederO as the validation reqionse of the Spam Processor. 

The specific programming syntax or execution logic of the ASL Manager rules 
prooessiiig may be varied in any suitable manner depending on the developer of the Spam Processor 
applipnt i™ The following examples of some options for ASL Manager actimis illustrate a wide 
range of approaches that may be used: 
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MATCmNO AN EMAIL ADDRESS OR ADDRESS PATTERN: 

(a) De&ilt exact match 

(b) A qiedfioemaU address: jofan@cocq>aiiy.C(im 

(c) UNDC Standard wildcard oiatdung: 

*.ioiciosod.ooiD = aiQfdiing fiom **MicioBoft.coiD*’ 

*nucrosofi* ^ anything widi mioosoft in it 
* jnQ = any email fiom die nulhaiy 

(d) my ViHwn “hladrlinla lirf* liy Being a %BLACKHQLE% symbol. 

USING A CONDmONAL AND PARAMETERS TO EXECUTE IF THE MATCH 

ismuE 

USING A SECONDARY ACTION AND PARAMETERS TO PERFORM IF 1HB 
OONDmONAL IS TRUK 

USING THE LAST DATE THE SUBSCRIBER SENT EMAIL TO THIS 
ADDRESS 

USING THE LAST DATE THIS ADDRESS SENT EMAIL TO THE 
SUBSCRIBER 

USING DATE THE RECORD WAS CREATED 

EXAMPLES OF CONDmONALS THAT CAN BE USED; 

(a) Eiqdration dates: use a given address until 2/1 2/2004 

(b) Dale ranges: use a pven address fiom 4/1/2004 to 5/2/2004 

(c) Specific recurring timea: first wedr of eviay numdi but no other tinie^ e.g.( 
newslettg<g >niaff«ziiiejiftm aeceptable during 1 " week of each monfii. 

(d) A link to external software designed to ^Iqw for additional uSer-defined criteria; 
this allowB for third party i^Ucations 

EXAMPLES OF MESSAGES THAT MAY BE INVOKED BY A GIVEN 
SECONDARY ACTION 

(a) Standard **enor^ 

(b) Quttan with variable substitution in tile message bo^,e.g.: 

%usenume% is substituted with the sender’s email address 
%8ubid% is the ID code of tile sntBcriber 
%daie% is today's date 

(c) liello %usemame94 you have been identified as spam, go to 

httD://Sv¥m.Biianikaou.coro /8idi8CTiber=^^ and if you’re realty human we’ll let 

you in. 

(d) Custom text; "All onail addresses from Ainerica Online are unconditionally 
rejected” 

(e) Send a given message in the error response. 

(f) Send a given message as an email. 
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(g) Open a file and email its contents 

(b) Open a file and send its contents as an euoi' leponse. 

0) Set the sendor’s status to SPAMMER (V FRIB^ 

0) Create a unique ©that wifi expire after a short time paiod(24-48hrs). This id 

can be used by the SUSPECT to access the WBM and become a CONTACT . 

(k) Give SMTP definiltenor message 

0) Link and execute external software deagned to allow for additional user-defined 

actions; this allows iortiurd party qpplicatitms. 
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IQ In summary, tiie present irrventi<m provides a q>am email rejection m ethod which 

analyzes fliie sender address of iscoming email and drtennines wdiether it is to be rgectcd u 
accqitod dependiOB upon mamged lists of audiorized senders. This is a significant d^arture fiom 
mrtaring pcocessing systems whidi accqit all email and attempts to filter out only those 

tiiat have sender recognized as those of known spammers. The invention method does 

15 not fiitw out enmil, rutiier it ityects all email unless authorized. The ASL Manager in 

the system captures and analyzes sender and lectyicnt usage pattenra for outgoing and i n e o ming 
in order to iwfine tire "authorized senders" lists. The analysis of this data provides a rich 
foundation fiwrules-based decisions as to which aender addresses are considered SPAMMER and 
wfaidi are not This data creates an "authorized seodet" list of FRIENDS, as opposed to a list of 
20 known SPAMMERS, thereby ensuring that no unsoticited «■ uninvited email will ever pass tiuougb 
to die SUBSCRIBER'S eamil box. 

It is understood that mar^ otiier modifications and variations may be devised given 
tile above description of tiie guiding prindples of Che invention. It is intended tiiat all sudi 
25 nv^’^t**^**""* and variations be considered as within the qiirit and scope of this invention, as 
defined in the foUowing claims. 
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KCLAffil; 



10 



I. A system for dimmatiog a na nth ori t 

copiprim'iig; I 

(b) an email client for allowing the usA 
addressed to a uniijne coudl address of the ussTi 

(b) an email-ieceiviiig server oonnected b 
^ receiving enoail addressed to tbe unique e ma i l addresi 

having an aufooxized scodeis list (ASL) rnodnle which mi 

senders aufooiued to send etnail to tbe aser> and - 

(c) an xqjection module operable 
receipt of email addressed to tbe emaO address of the use 
one is maintaiiied on too ASL list for foe user. 



d «<"im 1 sent to a user on a netwoik 

) 

to receive tmm\ sent on foe netwoik 

ptweeo foe netwoik and foe email client 
of foe user, said erttail-reoeiving server 
otains art ASL lid of email addresses of 

rifo foe ASL module for rgectbig foe 
if foe email address of foe sender is not 
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2. A system according to Claim ^ wher : 
for storing ASL lists of anfootized sender adUi s 
system, a spam processor module bv dieddng foe ASL lis 
dreating, maintaining, and updating foe ASL lists. 

' 3. A system accoidiiig to Claim 2, forfoer ci 

wifo foe ASL module for reeeivnig an email-saidiiig me 
«M pj<Qg and intended recipienf s TO address, for bending 
processor module to detennine wfaefocr foe sender's FROM 
address tnalntninad an the ASL list oonespondiiig to foe IX 
accepting the em «i if a matdi to an anthoxized soider addre 
if no match to an aufooiized sender address is found on foeA 



in the ASL module includes an ASL 
sses for respective subscribers of the 
I for matches, and an ASL manager for 



impiising a redirector module operable 
sage designating foe sendo^s FROM 
a request for validation to die qiam 
ddress matches any anfootized sender 
addr» of the intended recipient, 

! s is found, and for rejecting the email 



4. A system according to Claim 3, fotfoo' pomiprising a wd>-based me ssagi n g 
30 (WBM) module to which onail rejected by the redirector me dule is redirected and wUeb sends a 
mrnffn ge to foe address of the sender of tiie rejected email ho ifying the sender to confimi that the 
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seiKlcr is a l^tmute sQxider of enuul to the inteodU 



5. A syatem aooorfmg to Claim 4Awbeidm the WBM module includca a sepanto 

web site to which the iK>tified sender cim log on and fconto 

fi pyi il tbxoogh an inteiactioix procedure Mduch can only be performed by a humait 

6. A ayaton according to Claim 5. iheicin foe intewetira procedure includes a 
display of a gitQdiie image of a word in a rron^standarcflfonl, and an mput for die sender to enter in a 
word correspondir^ to the gra^diic image of the wor|^ wheidry the system cari confirm diat die 



interacdoo procedure is not performed by a mechanical 



brograni« 



7. A system according to Gaim 4, 
I^jdmate sender of email to die intended recipient 
user’s email box with acode dial indicate s that the 
confinned as legidmate by die WBM module* 



whcreiii once the sender is confirmed as a 
us^, the WBM module sends the email to the 
emfl^ was rejected by the redirector module but 



finv 



8. A systmn accoidmg to Claim 3, 

for c^tuiing I^OM »ul TO addresses of email acc^fed 
dam to foe ASL manager fix later analysts. 



per conqirising an email'-ieceiving manager 
by the redirector module and sending die 



9. A system according to Gaim 2» fiirtii 
c^rtuiing FROM and TO addresses of email sent fitnm 
ASL manager fix later analysis. 



10. A system according to Gann 2, 



rules inooessor fix processing predefined address capture 



gnto 



6um an onail address source selected fiem foe 
received email; sent email; usx inputs to email servi^ 
user browsiiig of web sites; user desktop organizer 
program inputs. 



anb 



icr ctmoprising an email-sending manager for 
the client and sending the data to die 



4focrein the ASL manager further includes a 
rules for updating foe ASL lists using data 



of email address sources consisting of: 
fimedons on foe email client; iiqiuts fiom 
other contact fists; and diird party address 
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11. A system aconiding to Oaim 2J wherdn llic ASL manager fintfwr conyrises a 
rules processor fbr processing predefined analysis rues for iqidating the ASL lists unng data fimo 
an analysis source selected from frte grmq> of analyse sources consisting ofi user email log analysis; 
eiqrtratioin date analysis; low/high email volume analysis; friazy logic analysis; and thiid party data 
5 analysis. 
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12. A qutem according to Claim 2, 
lists designating a sender-address status selected 
consisting ofrahwysaufrKirized as a friad;anflK>rit!e|l 
friend before an ex|»ration dafo; always rejected as 
black list; and rgccted as a spammer sent with to 



' tdureiii the ASL manager maintains the ASL 
from the gioig> 'Of seoder'-addresa statuses 
as a friend over a date range; authorized as a 
a|tpainmer, njected as a q;iatniner matching a 
message. 



tetnrf 



13. A method for diminating unanl lorized email sent to a user on- a networit 
comprising frie stqn ofr 

(a) icodving email addressed to' the unqne email address of the user, 

maiiitHimTig m aufootized senders list (ASL list) of email addresses of external 
users andiorized to send email to foe user, and ^ 

(c) rejecting foe recent of email sent jo foe email address of the user if the snail 
address of foeseuder is not one maintained on foe ASLjliBt foe user. 

14. A method according to Claim 13, frirfoer ccmiprising foe step of redirecting foe 
rejected email to a web site for sending a message to t le^sender of foe rejected email notilying the 
sender to confirm foat foe sender is 8 legitimate sender ( f email to foe inteaded redpieot 



25 15. A method according to Claim 14, fijrther comprising foe' stq> of perfonniQg an 

interaction procedure at foe wto site with foe notified {sender which can only be.pafonned a 
human. 



16. A method according to Claim 13, wherein said ASL list maintaining stqr 
30 includes updating the ASL lists using data captured fie n any of foe following sources: received 
email: sent email; user iiqjuts to email serWee functions i^uta fiem user browsing of web sites; 



■ 20 - 




o 

o 

tn 

(0 

to 

O 



a 

to 

ru 

in 

C3 

a 



25 



Ihiid paity address progrm inin^ 



user desktop oiganizer and odier contact lists; and 



17. A method accoiding to Gaim 13, wherein said ASL list tnaintaining stq> 
includes Uk ASL lists.unns data ohtainsp fioni analysiB of'any of die following lactois; 

user email log analysis; expiiatioo date analyBiB;| 
analysU; and dnid party data anafysis. 



low/hi^ email volume analysis; liiz^ logic 



IS. An email server system for elimi uding unauthorized email sent via a network to 

the server addressed to a unique email address ibr ai serof die system conqnising: 

(a) an autbaized senden list (ASL) module whidi m a inta i ns an ASL list of e m al 
addresses of sendere autbcHized to send email to die 1 ser, and 

(b) an email rejection module opei ible with the ASL module for rejecting the 
lece^t of email addressed to the email address of dii n 
one diat is maintained on tbo ASL list for the user. 



IS 



accord^ 



19. An email server system 
sn ASL database for storing ASL lists o: 
subscriben of the syston, a span piocessOT module 

ry 

ASL manag er for Creating, mahitaining, ami iqidatiBg 



user if die emafl address of die sender is not 



to C laim .19, vriierein die ASL module 
aothorized sender addresses for respective 
filr c bwJfing die ASL lists for tnatohea, and on 



s ASL lists. 
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20. An email server system according |o Claim 19, further comprising a redirector 
operable widi the ASL module for receiviDa an email-aending message dsaignatiiig the 
sender's FROM address and intended reetpienf s TO adfress, for sending a request for validation to 
the spam processor module to determine wbedier tne sender's FROM address m a tche s any 
suthoiized sender address maintained on die ASL list corresp ondin g to tbe TO address of the 
intended recipient, for aeoepting the email if a match to m authorized sendo* address is found, and 
for Injecting the email if no matdi to an authorized sendei address is found on the ASL UsL 
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ABSTRACT OP THE DISCLOSURE 



A system for ein«m«riiig uoantborized email sent to a user on a netwodc 6aq>loys an 
enudl'ieceiviiig server connected between the netwoifc and flie usa*8 e m a il dient for receiving 
y m nit addressed to the user and ngectiog diose in wbicli foe sender addrere does not match iuiy of 
maintained on an "aufoorized soideBs'' list (ASL list). The ASL lists are 

mafatained by an ASL manager m an ASL database (qierable wifo a spam inocessor module. A 

redirector rgects foe email iqxm sending a request for v a l id ati on to foe spam processor 

modulet foe sender’s address does not match any anfoonzed s end e r address on foe ASL list. Bmail 
lejcctod by foe redireetor module is redirected to a web-based m ess ag in g (WBM) module which 
g message to the soadiar to confirm that foe sender is a legitnnate se nder of w i wl to the . 
recipient. If foe sender logs on to coofinn foeir statos, the WBM module executes an 
interaction procedure which can only be perfon ned by a hunmn, in order to ensure that foe 
f^fiimarinn procedure is not perfonned by a mechanical program. The ASL manager m a int ai n s 
foe ASL Bstt based iqion sender address data collected fiom various sources and analyses of various 
rmnix usagc fiuSoxs, including Sent email, received email, contact lists maint a ine d by foe user, user 
preference irqiuts, third party programs, do. 
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